Linux SCSI subsystem development
 help / color / mirror / Atom feed
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 0/2] scsi: scsi_debug: fix zoned write validation
Date: Thu, 17 Sep 2026 10:45:54 +0200	[thread overview]
Message-ID: <20260917084553.559765-4-cassel@kernel.org> (raw)

scsi_debug does not enforce all of the requirements that ZBC places on a
write to a sequential write required zone, and one command bypasses the
zone checks altogether. Both let the emulation accept a write that a
conforming device would terminate, and leave the zone in a state that
the kernel cannot work with.

Patch 1 adds the missing check that the ending LBA of a write falls on a
physical block boundary. Without it, a single logical block write at the
write pointer of a sequential zone is accepted on a device whose
physical block size is larger, and leaves a write pointer that is not a
multiple of the zone_write_granularity reported for the device. Nothing
can then write at that position at the granularity the kernel
advertises, and the zone can only be used again after being reset.

Patch 2 makes WRITE ATOMIC (16) go through the same zone validation as
every other write. resp_atomic_write() calls do_device_access()
directly, so an atomic write is accepted anywhere in a sequential zone
regardless of the write pointer, and the write pointer is never
advanced, which leaves REPORT ZONES describing something other than what
is on the medium.

The two are independent, but the order matters slightly: once patch 2
routes atomic writes through check_zbc_access_params(), the check added
by patch 1 applies to them as well.

Neither defect is reachable in a default configuration. Patch 1's check
is a no-op with the default physblk_exp=0, where the physical block size
equals the logical block size, and patch 2's path needs atomic_wr=1,
which defaults to off. That is presumably why both have gone unnoticed.

Tested on a zoned scsi_debug device with 512 byte logical blocks and a
4096 byte physical block:

  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

Before the series, a one block WRITE(16) at a sequential zone's write
pointer completes with GOOD status and leaves the write pointer at LBA
0x18001, and a WRITE ATOMIC (16) is accepted both at and past the write
pointer without advancing it. After it, all three are terminated with
ILLEGAL REQUEST / UNALIGNED WRITE COMMAND, while an aligned eight block
WRITE ATOMIC (16) at the write pointer advances the write pointer by
eight blocks. Writes to conventional zones are unaffected.

Niklas Cassel (2):
  scsi: scsi_debug: Enforce physical block alignment of zoned writes
  scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

 drivers/scsi/scsi_debug.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

-- 
2.55.0


             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 Niklas Cassel [this message]
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 ` [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=20260917084553.559765-4-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