All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Niklas Cassel <cassel@kernel.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <mkp@kernel.org>
Cc: 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 16:05:54 +0700	[thread overview]
Message-ID: <b7472e4a-cf81-4e3d-b44a-94b06214ca5f@kernel.org> (raw)
In-Reply-To: <20260917084553.559765-5-cassel@kernel.org>

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?

Either way,

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2026-09-17  9:05 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 [this message]
2026-09-17 10:42     ` Niklas Cassel
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=b7472e4a-cf81-4e3d-b44a-94b06214ca5f@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=cassel@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.