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 v3 6/6] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)
Date: Thu, 17 Sep 2026 20:15:05 +0700 [thread overview]
Message-ID: <5cd95afa-b9d6-4993-a221-1560df8978dc@kernel.org> (raw)
In-Reply-To: <20260917125445.1376493-14-cassel@kernel.org>
On 2026/09/17 19:54, Niklas Cassel wrote:
> 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. The zone metadata write lock is already taken
> across the access for the provisioning map; take it for a zoned device
> too, as the write pointer has to be read and updated atomically with
> respect to other commands. Unlike an ordinary write, the write pointer
> is advanced only when all of the data was written, as an atomic write
> either completes or has no effect.
>
> Assisted-by: LLM
> Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
See my comment on v2.
> ---
> drivers/scsi/scsi_debug.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 33f2df26e5af..b57d25d7214c 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -6229,15 +6229,29 @@ static int resp_atomic_write(struct scsi_cmnd *scp,
> }
> }
>
> - if (scsi_debug_lbp()) {
> + if (sdebug_dev_is_zoned(devip) || scsi_debug_lbp()) {
> sdeb_meta_write_lock(sip);
> meta_data_locked = true;
> }
>
> + ret = check_device_access_params(scp, lba, len, true);
> + if (ret) {
> + if (meta_data_locked)
> + sdeb_meta_write_unlock(sip);
> + return ret;
> + }
> +
> ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
> if (unlikely(scsi_debug_lbp()))
> map_region(sip, lba, len);
>
> + /*
> + * If ZBC zone then bump its write pointer, but only if all of the data
> + * was written: an atomic write either completes or has no effect.
> + */
> + if (sdebug_dev_is_zoned(devip) && ret == len * sdebug_sector_size)
> + zbc_inc_wp(devip, lba, len);
> +
> if (meta_data_locked)
> sdeb_meta_write_unlock(sip);
>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2026-09-17 13:15 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 ` [PATCH v3 4/6] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-17 13:09 ` 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 [this message]
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=5cd95afa-b9d6-4993-a221-1560df8978dc@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.