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 4/6] scsi: scsi_debug: Enforce physical block alignment of zoned writes
Date: Thu, 17 Sep 2026 14:54:50 +0200 [thread overview]
Message-ID: <20260917125445.1376493-12-cassel@kernel.org> (raw)
In-Reply-To: <20260917125445.1376493-8-cassel@kernel.org>
ZBC-3 r06 (T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern
requirements for sequential write required zones, states:
The device server terminates with CHECK CONDITION status, with the
sense key set to ILLEGAL REQUEST, and the additional sense code set
to UNALIGNED WRITE COMMAND a write command, other than an entire
medium write same command, that specifies:
a) the starting LBA in a sequential write required zone set to a
value that is not equal to the write pointer for that sequential
write required zone; or
b) an ending LBA that is not equal to the last logical block within
a physical block (see SBC-5).
That is why sd_zbc_read_zones() sets the zone_write_granularity queue
limit to the physical block size of a host-managed device, exposing the
constraint to user space.
check_zbc_access_params() implements condition a) but not condition b):
it verifies that a write to a sequential write required zone starts at
the write pointer of the zone, but never validates the ending LBA. As a
consequence, when scsi_debug emulates a host-managed device whose
physical block size is larger than its logical block size, for instance
with zbc=managed sector_size=512 physblk_exp=3, a write of a single
logical block at the write pointer of a sequential zone is accepted and
advances the write pointer by one logical block. The write pointer is
then no longer a multiple of the zone_write_granularity reported for the
device, so nothing can write at it at the granularity that was
advertised, and the zone can only be used again after being reset.
Implement condition b) as well, with the same sense data as the write
pointer check, as the standard gives both conditions the same sense key
and additional sense code. The exclusion of an entire medium write same
command needs no special case: such a command spans the whole medium, so
it is already terminated with WRITE BOUNDARY VIOLATION by the preceding
check.
The check is placed in check_zbc_access_params(), which every command
that advances a zone write pointer reaches first: WRITE, WRITE SCATTERED
and WRITE SAME. Reads return earlier in the function and are unaffected.
Sequential write preferred zones, which are emulated for host-aware
devices with zbc=aware, are left alone: writes to them are not required
to be sequential, and Linux does not restrict the write granularity of
host-aware devices.
With the default physblk_exp=0, the physical block size equals the
logical block size and the new check is a no-op.
Assisted-by: LLM
Fixes: f0d1cf9378bd ("scsi: scsi_debug: Add ZBC zone commands")
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
drivers/scsi/scsi_debug.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 41c8d958f445..64f32d97455d 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -3980,6 +3980,16 @@ static int check_zbc_access_params(struct scsi_cmnd *scp,
UNALIGNED_WRITE_COMMAND);
return check_condition_result;
}
+ /*
+ * Writes must end on a physical block boundary, that is, the
+ * transfer length must be a multiple of the physical block
+ * size.
+ */
+ if (!IS_ALIGNED(lba + num, 1U << sdebug_physblk_exp)) {
+ mk_sense_buffer(scp, ILLEGAL_REQUEST,
+ UNALIGNED_WRITE_COMMAND);
+ return check_condition_result;
+ }
}
/* Handle implicit open of closed and empty zones */
--
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 ` Niklas Cassel [this message]
2026-09-17 13:09 ` [PATCH v3 4/6] scsi: scsi_debug: Enforce physical block alignment of zoned writes 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 ` [PATCH v3 6/6] scsi: scsi_debug: Validate zone access for " Niklas Cassel
2026-09-17 13:15 ` 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-12-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