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 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)
Date: Thu, 17 Sep 2026 10:45:56 +0200 [thread overview]
Message-ID: <20260917084553.559765-6-cassel@kernel.org> (raw)
In-Reply-To: <20260917084553.559765-4-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, holding the zone metadata write lock across both,
since the write pointer has to be read and updated atomically with
respect to other commands.
Assisted-by: LLM
Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
Tested with:
modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2 atomic_wr=1
issuing WRITE ATOMIC (16) with sg_raw. Before this patch, an eight block
atomic write at the write pointer of an empty sequential write required
zone completes with GOOD status and leaves the write pointer unchanged,
and one issued past the write pointer is accepted as well. After it, the
former advances the write pointer by eight blocks and the latter is
terminated with ILLEGAL REQUEST / UNALIGNED WRITE COMMAND.
A two block atomic write at the write pointer, which satisfies
atomic_wr_gran and atomic_wr_align but is smaller than the 4096 byte
physical block, is now rejected by the check added in the previous
patch. An atomic write to a conventional zone is unaffected.
---
drivers/scsi/scsi_debug.c | 13 +++++++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -6043,7 +6043,24 @@
}
}
+ if (sdebug_dev_is_zoned(devip))
+ sdeb_meta_write_lock(sip);
+
+ ret = check_device_access_params(scp, lba, len, true);
+ if (ret) {
+ if (sdebug_dev_is_zoned(devip))
+ sdeb_meta_write_unlock(sip);
+ return ret;
+ }
+
ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
+
+ /* If ZBC zone then bump its write pointer */
+ if (sdebug_dev_is_zoned(devip)) {
+ zbc_inc_wp(devip, lba, len);
+ sdeb_meta_write_unlock(sip);
+ }
+
if (unlikely(ret == -1))
return DID_ERROR << 16;
if (unlikely(ret != len * sdebug_sector_size))
--
2.55.0
next prev parent reply other threads:[~2026-09-17 8:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 8:45 [PATCH 0/2] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-17 8:45 ` [PATCH 1/2] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-17 9:05 ` Damien Le Moal
2026-09-17 10:42 ` Niklas Cassel
2026-09-17 8:45 ` Niklas Cassel [this message]
2026-09-17 9:00 ` [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16) sashiko-bot
2026-09-17 9:09 ` Niklas Cassel
2026-09-17 9:07 ` Damien Le Moal
2026-09-17 9:38 ` John Garry
2026-09-17 9:56 ` Niklas Cassel
2026-09-17 10:26 ` John Garry
2026-09-17 10:35 ` Niklas Cassel
2026-09-17 15:42 ` John Garry
2026-09-17 16:10 ` Niklas Cassel
2026-09-17 16:40 ` John Garry
2026-09-17 17:37 ` Niklas Cassel
2026-09-18 2:27 ` Damien Le Moal
2026-09-18 5:37 ` Niklas Cassel
2026-09-18 6:15 ` Damien Le Moal
2026-09-18 7:06 ` Christoph Hellwig
2026-09-18 7:27 ` Niklas Cassel
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=20260917084553.559765-6-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