From: Niklas Cassel <cassel@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <mkp@kernel.org>,
linux-scsi@vger.kernel.org, John Garry <john.garry@linux.dev>
Subject: Re: [PATCH 1/2] scsi: scsi_debug: Enforce physical block alignment of zoned writes
Date: Thu, 17 Sep 2026 12:42:23 +0200 [thread overview]
Message-ID: <aqvEDwt5b2-LsIG6@ryzen> (raw)
In-Reply-To: <b7472e4a-cf81-4e3d-b44a-94b06214ca5f@kernel.org>
On Thu, Sep 17, 2026 at 04:05:54PM +0700, Damien Le Moal wrote:
> On 2026/09/17 15:45, Niklas Cassel wrote:
> > 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")
> > Signed-off-by: Niklas Cassel <cassel@kernel.org>
>
> Looks good, but that will be another conflict with linux-next...
> May be rebase the fix on scsi-staging and let's push it to 7.4 instead?
Considering that the fixes are only for a moduled used for debug,
I can do that.
Will rebase on mkp/7.4/scsi-staging
Kind regards,
Niklas
next prev parent reply other threads:[~2026-09-17 10:42 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 [this message]
2026-09-17 8:45 ` [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16) Niklas Cassel
2026-09-17 9:00 ` 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=aqvEDwt5b2-LsIG6@ryzen \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.