From nobody Sun Feb 8 13:28:15 2026 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5EA72F616A for ; Thu, 5 Feb 2026 17:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770313200; cv=none; b=XKq1H9ODxoJSxEUu82PaksDRcq/Kucz82kDYGPKCGB1RK2Vt/pqxrHxVqc4mBh32ix9DL8TrYCj3Pb7m06fXYN6Fn7MjFPhTfeekIiYA0WIP+X+l+rzf3LIPGTr0aPDxlwZNtFEXio5COmEywo+DEvJjBPNuLi2NCB6UohhXO38= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770313200; c=relaxed/simple; bh=XNMHHJguSN5BclgVIkPWZkUfWieiYIzVEUynIB2F+og=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=DJb8cJf8uBG+8sn9ia6PDvfw2RZElmB5+0iMV4ENVsIaPcXETThkzJw3k223tWwjExOBH7yuZ5s4Pqmd5O3zksiqxFJf0XQTD4OhhI9qCTQqwixgfJWQmkNXfab6Ql/c3TMPR2ToakGWFZmQwKaH+cIdK/d+4dzzSthKWU7boh4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com; spf=pass smtp.mailfrom=linbit.com; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b=KAsRUpRK; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b="KAsRUpRK" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4801ea9bafdso7658845e9.3 for ; Thu, 05 Feb 2026 09:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linbit-com.20230601.gappssmtp.com; s=20230601; t=1770313198; x=1770917998; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=wdr0IwDMGGG3tNroL/3nN4LO0wiu5miJzO4pgtEfhC0=; b=KAsRUpRKUoGgDFmeCmV9/c71Vo+ptHGmCuDpcEbsIIENNHAVsf7UfLAKljpwPDQ+cF lJ5ty6xOlPdwA4Pmy8jeDyDVDsm57KVaDYAPrT3oaJ151aYy8EC6SIufZ4OLJHuuneEO baHJLPgp9PEZMJz3xgbOPrMRqQRlsO93aIE5oQUgLOLwPOftP668iqc2ky65Zlc94BCB sDF1RHboLSI2Ib4ezYu1ep27ef5uCLEeM8d7eM7B2SR4+QeuHF3X6LI179jV4r3K94C4 FQOo+PEr6WE/SgMiNena5LpEBGYHoo5UgLn0/e8QuS7Bq4KnJz1Ejl04uY0KIYuVfXbG Q/5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770313198; x=1770917998; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wdr0IwDMGGG3tNroL/3nN4LO0wiu5miJzO4pgtEfhC0=; b=Nspv7CGkZZYN6M7MA28pCFeSjnSn4pmVCYEeyS8efdwoOaMSS9QYsGn4JPitW0Apu/ bg+O0g0VgNm3f7NKBr0N5jq6bvD6b/1+mlhFrd6IjRct1csuIuXZuFJUfumfDhzzajk9 RAL4HZi9boulEhgKuBr7uX7lP3IP4hnf+A7fgK4VsYOa7mYLjCWuV+nEVZ9nrw/+BB4a 4w59XjPoHzldD+o61BR9GP1JohrvnwJ3xYPXYePq31YzJ63QJAi8vttnJRCX59h1Abh+ KxF6Ya/KGDLfqvLyawG4MEPyIrRB6JnW+Qp3zPgYo1rJbtD5dkXwsYvBso137vFeerdR UBAA== X-Forwarded-Encrypted: i=1; AJvYcCUVEjj+aVt+xbg89SnXZqYM3bz0nHo3j+rBlEoKCUcT09O03Xm5XT5Zx0ewMGDOTsmrHSdfynIrIW8oFWk=@vger.kernel.org X-Gm-Message-State: AOJu0YyUduf4bMl3p0vkNVNdr3QpnYoYiMgKHAEYjCUw0X6LUOAug0k/ sPEUfnKYGlNCHucoe0Uv9gx4hkOd9l0bm1VLw9f5kIZovZvWOUSxN+pV3BAF9o83pDJN+X6uUjA KDJEl X-Gm-Gg: AZuq6aIAM7cUVykD18nt+BY0b0zKE0xLcwHfyn4L5RaC5iNWjmwQVOdfpkRuKUbEGgl OSNnPUwBBa0wECh3/Dm3wvFveu9u0ikUSjyt6IR55xvBrK2UKGNFHqQ8Xw15yKVQeyf5nZ8LEds ZwX4qZet6kod5v8cPt9X+UZFwjWJgQasx+5WxvCT/HpKvVVscZfW8jk+EbTNOZyGQOJYC8PKJMZ i/lzz1amEVZHwehCb7bl/eCk0Lkzp0d8wPu1xJiCLwYUVdKImVhuLQEmgJAioN9By//FZN13K4Z CgAFG/1G/1MjrK5IGZ7H6SbE3a7CKyGhugnEh4wcK0huadAHFxf70kegl/aBxAljFnL8Lb3PMHA ivY73AOCVVjkgyf1vZchNgna8YW3JvkSE3/I/IVQE1sLj3vCeyYvhdI/yfkFUDDTNxBLQeabY84 J6mFkMQeA0M4E6zqJldwYjUdPpa3+3xNCpy4KZgL/5zp5s2dtKjhdVqJZKlcDAXsRPqUup0OfsS 7TX1PlU0g== X-Received: by 2002:a5d:630c:0:b0:436:1896:e1e3 with SMTP id ffacd0b85a97d-4362924101dmr57832f8f.9.1770313197976; Thu, 05 Feb 2026 09:39:57 -0800 (PST) Received: from localhost.localdomain (h082218028181.host.wavenet.at. [82.218.28.181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43617e25cefsm16559622f8f.9.2026.02.05.09.39.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 09:39:57 -0800 (PST) From: =?UTF-8?q?Christoph=20B=C3=B6hmwalder?= To: Jens Axboe Cc: drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org, Lars Ellenberg , Philipp Reisner , linux-block@vger.kernel.org, =?UTF-8?q?Christoph=20B=C3=B6hmwalder?= Subject: [PATCH] drbd: always set BLK_FEAT_STABLE_WRITES Date: Thu, 5 Feb 2026 18:39:29 +0100 Message-ID: <20260205173928.3166880-2-christoph.boehmwalder@linbit.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable DRBD requires stable pages because it may read the same bio data multiple times for local disk I/O and network transmission, and in some cases for calculating checksums. The BLK_FEAT_STABLE_WRITES flag is set when the device is first created, but blk_set_stacking_limits() clears it whenever a backing device is attached. In some cases the flag may be inherited from the backing device, but we want it to be enabled at all times. Unconditionally re-enable BLK_FEAT_STABLE_WRITES in drbd_reconsider_queue_parameters() after the queue parameter negotiations. Also, document why we want this flag enabled in the first place. Fixes: 1a02f3a73f8c ("block: move the stable_writes flag to queue_limits") Signed-off-by: Christoph B=C3=B6hmwalder Reviewed-by: Christoph Hellwig --- Note: this commit is based on the for-6.19/block tree in case it is still possible to take it into the 6.19 release as this *could* lead to silent data corruption. However, due to other protection mechanisms in DRBD, this is relatively unlikely to happen in the real world and we have not seen any corresponding reports from users. So if this only lands in 6.20/7.0, it is also fine. drivers/block/drbd/drbd_main.c | 3 --- drivers/block/drbd/drbd_nl.c | 20 +++++++++++++++++++- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index c73376886e7a..1f6ac9202b66 100644 --- a/drivers/block/drbd/drbd_main.c +++ b/drivers/block/drbd/drbd_main.c @@ -2659,9 +2659,6 @@ enum drbd_ret_code drbd_create_device(struct drbd_con= fig_context *adm_ctx, unsig * connect. */ .max_hw_sectors =3D DRBD_MAX_BIO_SIZE_SAFE >> 8, - .features =3D BLK_FEAT_WRITE_CACHE | BLK_FEAT_FUA | - BLK_FEAT_ROTATIONAL | - BLK_FEAT_STABLE_WRITES, }; =20 device =3D minor_to_device(minor); diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c index 91f3b8afb63c..b502038be0a9 100644 --- a/drivers/block/drbd/drbd_nl.c +++ b/drivers/block/drbd/drbd_nl.c @@ -1296,6 +1296,8 @@ void drbd_reconsider_queue_parameters(struct drbd_dev= ice *device, lim.max_segments =3D drbd_backing_dev_max_segments(device); } else { lim.max_segments =3D BLK_MAX_SEGMENTS; + lim.features =3D BLK_FEAT_WRITE_CACHE | BLK_FEAT_FUA | + BLK_FEAT_ROTATIONAL | BLK_FEAT_STABLE_WRITES; } =20 lim.max_hw_sectors =3D new >> SECTOR_SHIFT; @@ -1318,8 +1320,24 @@ void drbd_reconsider_queue_parameters(struct drbd_de= vice *device, lim.max_hw_discard_sectors =3D 0; } =20 - if (bdev) + if (bdev) { blk_stack_limits(&lim, &b->limits, 0); + /* + * blk_set_stacking_limits() cleared the features, and + * blk_stack_limits() may or may not have inherited + * BLK_FEAT_STABLE_WRITES from the backing device. + * + * DRBD always requires stable writes because: + * 1. The same bio data is read for both local disk I/O and + * network transmission. If the page changes mid-flight, + * the local and remote copies could diverge. + * 2. When data integrity is enabled, DRBD calculates a + * checksum before sending the data. If the page changes + * between checksum calculation and transmission, the + * receiver will detect a checksum mismatch. + */ + lim.features |=3D BLK_FEAT_STABLE_WRITES; + } =20 /* * If we can handle "zeroes" efficiently on the protocol, we want to do base-commit: b1e5c96ab4a011763afac033f6660cf1eb499458 --=20 2.52.0