From: Niklas Cassel <cassel@kernel.org>
To: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <mkp@kernel.org>
Cc: linux-scsi@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>,
John Garry <john.garry@linux.dev>,
Niklas Cassel <cassel@kernel.org>
Subject: [PATCH v3 6/6] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)
Date: Thu, 17 Sep 2026 14:54:52 +0200 [thread overview]
Message-ID: <20260917125445.1376493-14-cassel@kernel.org> (raw)
In-Reply-To: <20260917125445.1376493-8-cassel@kernel.org>
WRITE ATOMIC (16) is a write command, so on a zoned device it is subject
to the access requirements of the zone that it addresses, and it advances
the write pointer of a sequential write required zone. See ZBC-3 r06
(T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern requirements for
sequential write required zones.
resp_atomic_write() calls do_device_access() directly, without calling
check_device_access_params() first and without advancing the write
pointer afterwards. It is the only command that writes user data which
does not; WRITE, WRITE SCATTERED and WRITE SAME all go through
check_device_access_params(), which validates zone access for a zoned
device.
As a consequence, with zbc=managed atomic_wr=1, a WRITE ATOMIC (16) can
write anywhere within a sequential write required zone regardless of its
write pointer and zone condition, into a gap zone, or across a zone
boundary, and none of it is reflected in the zone state. The write
pointer is left where it was, so a subsequent REPORT ZONES does not
describe the data on the medium, and the next write at that write
pointer overwrites data that was written without error.
Validate the access and advance the write pointer the way
resp_write_dt0() does. The zone metadata write lock is already taken
across the access for the provisioning map; take it for a zoned device
too, as the write pointer has to be read and updated atomically with
respect to other commands. Unlike an ordinary write, the write pointer
is advanced only when all of the data was written, as an atomic write
either completes or has no effect.
Assisted-by: LLM
Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
drivers/scsi/scsi_debug.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 33f2df26e5af..b57d25d7214c 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -6229,15 +6229,29 @@ static int resp_atomic_write(struct scsi_cmnd *scp,
}
}
- if (scsi_debug_lbp()) {
+ if (sdebug_dev_is_zoned(devip) || scsi_debug_lbp()) {
sdeb_meta_write_lock(sip);
meta_data_locked = true;
}
+ ret = check_device_access_params(scp, lba, len, true);
+ if (ret) {
+ if (meta_data_locked)
+ sdeb_meta_write_unlock(sip);
+ return ret;
+ }
+
ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
if (unlikely(scsi_debug_lbp()))
map_region(sip, lba, len);
+ /*
+ * If ZBC zone then bump its write pointer, but only if all of the data
+ * was written: an atomic write either completes or has no effect.
+ */
+ if (sdebug_dev_is_zoned(devip) && ret == len * sdebug_sector_size)
+ zbc_inc_wp(devip, lba, len);
+
if (meta_data_locked)
sdeb_meta_write_unlock(sip);
--
2.55.0
next prev parent reply other threads:[~2026-09-17 12:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 12:54 [PATCH v3 0/6] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-17 12:54 ` [PATCH v3 1/6] scsi: scsi_debug: Report the residual of a write Niklas Cassel
2026-09-17 13:04 ` sashiko-bot
2026-09-17 13:06 ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 2/6] scsi: scsi_debug: Do not write a partial physical block Niklas Cassel
2026-09-17 13:11 ` Damien Le Moal
2026-09-17 13:47 ` Niklas Cassel
2026-09-17 12:54 ` [PATCH v3 3/6] scsi: scsi_debug: Advance the write pointer over the data written Niklas Cassel
2026-09-17 13:13 ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 4/6] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-17 13:09 ` sashiko-bot
2026-09-17 12:54 ` [PATCH v3 5/6] scsi: scsi_debug: Map the region written by WRITE ATOMIC (16) Niklas Cassel
2026-09-17 13:12 ` sashiko-bot
2026-09-17 14:01 ` Niklas Cassel
2026-09-17 13:14 ` Damien Le Moal
2026-09-17 12:54 ` Niklas Cassel [this message]
2026-09-17 13:15 ` [PATCH v3 6/6] scsi: scsi_debug: Validate zone access for " Damien Le Moal
2026-09-17 13:05 ` [PATCH v3 0/6] scsi: scsi_debug: fix zoned write validation Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260917125445.1376493-14-cassel@kernel.org \
--to=cassel@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dlemoal@kernel.org \
--cc=john.garry@linux.dev \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox