From nobody Tue Aug 25 14:34:36 2026 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 6186E34A773 for ; Fri, 14 Aug 2026 04:58:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786683498; cv=none; b=eGb9m/34iLJ6xhwzeCZ7PFDX+fAqia98QO4t45Ovt0qMmeLbuMJywD3SzX74J2og6wKPnRD9AqfOZfsJzCN1xksktkTPRRwFXQH4EmrpPMaFMdcXJ47nOKmrRbhZXCUDiJxcdMyxSejqDfaIsRSgIqgOYByN1SC5k0vNOCTMd1k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786683498; c=relaxed/simple; bh=x+q7w8x3NtSBHD+4DmbJVmqcKywElwy548VILEv1nBw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RlfwT59PTIkntYyIxlIr+N/jh5iQF8T8hUs65VmJrokJlg46eGg9uP9o8/doYhsW1q2ePKRfQRjXGjzRhpomG1p4bRm3DJm4beoBlHS3rFabVn/evL4e1ANq1Hmyk5jMZtiE8yKH43aSJH0+TxcG6yZcb5w6KphvG7lSJZ5dZi0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LuAzMuwA; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LuAzMuwA" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2cf6d65d8a7so8790355ad.0 for ; Thu, 13 Aug 2026 21:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786683497; x=1787288297; 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:content-type; bh=u447nzojyw2ofbi46saTWniS13rz4btfnPI1tc93bqI=; b=LuAzMuwAy5qdQDQX9ciznkDxwJEFi4KdOTUTT0vjlUfMBNEWh9TG1d9g2YjpPvpJXM zaynyrLLsZPTB7dYcmSdugga6Bfqgojs0oLZlisrc4skrx2zjPnodMHsXCFiyuRlJ53z L7prr6iDJxNtnP6rTqOGVu6LY6ownYSCd140XkLHE6tipKDe/V5gcodyxR/gcUgBYlFx Q3yLI0pQG0e22b0P59IxKZhyp4rSg7AfMuKGYBoZC/D8miJbKNZYVXoTkcQf8YjBmKJ5 Cfz/Z6wXnb2hypWnVqC+oSh97iZYscUTzusVGBxo3lHeIhZfVA4HwJFjyh+50Ay67gV+ ttgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786683497; x=1787288297; 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:content-type; bh=u447nzojyw2ofbi46saTWniS13rz4btfnPI1tc93bqI=; b=kx5OJ2tfo2jX0Qbut8t6bYuAcT5931J71ez7JTRstLHUnQ8A6Rm6+LQTin2pylbxXy ZCdtneNXNGVyDomy3wnA0z27GHM8rds/H6DIIMWQ35ntJGoB2C3WqMvzPaj65Wv10jmG scYfhLs2fsGGL5kF1tP8UYUF5Xkt0B09jEp+5x+6QfnKWVSqJs70Vhjtsk8fEmsS7cQY fLmgUzSzo+Fobkfw+Klee5u1iXirBfFoo2oXfaH+T4Ke1KlJlZsDr8hi7jb4bIk5wnSW m3Km76yw7CIFfSKCLZ1tdehT94il4zO4cFXfPjNOX+p/2dXdXytRo9Ywc8+hwflypdtZ ct3Q== X-Forwarded-Encrypted: i=1; AHgh+RoeHZiatxLAeM8JySacDg/EN9+rF0fQDkJvA3AMG3HweCAHl/zTIrBGuYpCeV0oiPMc9QxC2DBHfdpP5Dg=@vger.kernel.org X-Gm-Message-State: AOJu0YyYszRayJUxE+687SQJOdB6D6bRRSyN+a9bgb73yiDhb0Z0lrTS zW7oOb61fVaL0V5KTRCAi7527RvkIQzzUCR5CshhhBAg2/QtprASBKUm X-Gm-Gg: AR+sD10LrfF7ZaRPY1M8NYdfSTRWymJL3U6RC2/4KiIj3KCUdeVjw5xKK/GYfVn9xXh +dzH+cqogY9YvP6XCZOVAuXXeZ/k3HTbFdMf8LT/XqBXDIU8rp9dBYi5g1UUrSbqXpJs7+nIeIG hURqt+PehlWj22EQNxnsn9D7vdfFeqzDC+CQ79leMxt5cFDTf+F3Dj+2II/sXRHi1D9mbMKvX07 jRqrda1LBMy6S2hA5l/mtY7ZwMFr1mluGiLw69h5mMUEvYqnhXqOLWMgOZlvU3B/r2RSJH0CQJL j4v1/4/Q3zsQRyEezitkwgnOem6SGRPip+7RAJSCuGrk0T3CHMH6YdpTQidmJmLLPfLjPGWJdCN o2YFxJOd0FMZyPf2vzRmNYHdUIbY0Cny9ESrANMEcphzf54x14wF7BKX26HC7y0zLhDoxwzLxJ2 VjmCYCkVl0uJiZA9HFawSOZ1KOVV2mbwWmGfoh4ol8SpL588OarBsuFrH8WL3Zhsi81rbJPFcaI qr649hH2I/rIHBWGT4vMl4xmZLtJ6WKDG7IU4m/Fc0fqsjOeVP5TEcrEsQoBUYUftqlE3GKg+3E mPeo6BkMQW29JrdZXrml3nb1XNJKhh7i/IVY3flT1Z4S7mBazOJE X-Received: by 2002:a17:902:da83:b0:2ca:6d87:cda0 with SMTP id d9443c01a7336-2d3b08589ddmr26685545ad.6.1786683496611; Thu, 13 Aug 2026 21:58:16 -0700 (PDT) Received: from spider.bream-herring.ts.net ([103.252.203.158]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d3ae7a4c27sm4494325ad.27.2026.08.13.21.58.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 21:58:16 -0700 (PDT) From: Matthias Goergens To: dm-devel@lists.linux.dev Cc: agk@redhat.com, snitzer@kernel.org, mpatocka@redhat.com, bmarzins@redhat.com, linux-kernel@vger.kernel.org, Matthias Goergens Subject: [PATCH] dm-delay: advertise flush support Date: Fri, 14 Aug 2026 12:58:12 +0800 Message-ID: <20260814045813.3148127-1-matthias.goergens@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" dm-delay parses and reports a flush delay class (the 9-argument table form's ), delay_map() routes REQ_PREFLUSH bios to it, the target sets num_flush_bios =3D 1, and Documentation/admin-guide/device-mapper/delay.rst documents flush delays. But the target never sets ti->flush_supported, so dm_table_supports_flush() is false: the block layer strips REQ_PREFLUSH as a no-op before the bio ever reaches the target (blk_insert_flush()), REQ_FUA is stripped too, and the flush delay class is dead code. Anyone who configures a flush delay on dm-delay (e.g. to model slow-flush devices in tests) silently measures nothing. Set ti->flush_supported =3D true so the flush delay class is actually reachable. dm core clones empty flushes with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC (__send_empty_flush), which delay_map() already routes to the flush class, and delayed completion is already handled for every class by the delay worker. Verified with dm-delay over a virtio-scsi disk: without this change REQ_PREFLUSH completes immediately and REQ_FUA writes are stripped by the block layer; with it, flushes take the configured delay and FUA writes reach the wire (measured as device-time per MB at D_f =3D 200 ms and 800 ms flush delays). Signed-off-by: Matthias Goergens --- drivers/md/dm-delay.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-delay.c b/drivers/md/dm-delay.c --- a/drivers/md/dm-delay.c +++ b/drivers/md/dm-delay.c @@ -301,6 +301,7 @@ } ti->num_flush_bios =3D 1; + ti->flush_supported =3D true; ti->num_discard_bios =3D 1; ti->accounts_remapped_io =3D true; ti->per_io_data_size =3D sizeof(struct dm_delay_info); @@ -451,7 +452,7 @@ static struct target_type delay_target =3D { .name =3D "delay", - .version =3D {1, 5, 0}, + .version =3D {1, 5, 1}, .features =3D DM_TARGET_PASSES_INTEGRITY | DM_TARGET_ZONED_HM, .module =3D THIS_MODULE, .ctr =3D delay_ctr,