mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Simon Liebold <simonlie@amazon.de>
To: <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	<linux-scsi@vger.kernel.org>
Cc: Simon Liebold <simonlie@amazon.de>
Subject: [PATCH 5.15.y] Revert "scsi: sd: sd_zbc: Use logical blocks as unit when querying zones"
Date: Mon, 5 Oct 2026 15:07:13 +0000	[thread overview]
Message-ID: <20261005150713.3919586-1-simonlie@amazon.de> (raw)

This reverts commit 9c78f3cf7785f3de5afb3d632f0d81c2cb0e9020, the 5.15.y
backport of upstream 43af5da09efb.

43af5da09efb is a cleanup ("slightly simplifies sd_zbc_report_zones()"),
not a fix. It entered 5.15.y only as a Stable-dep-of: 93dde0bf2f39
("scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write"),
which touches only scsi_debug.c and does not actually depend on it.

On its own it zeroes the capacity of host-managed SMR drives at boot. It
changed the REPORT ZONES loop advance from

	sector += sd_zbc_zone_sectors(sdkp) * i;	/* sector_t, 64-bit */
to
	lba += sdkp->zone_blocks * i;			/* u32, wraps */

(zone_info.zone_blocks on 5.15.y after bffcb7d6a287). zone_blocks is
u32, so the product is computed in 32 bits and wraps before being
widened into the 64-bit lba. A drive returning >= 8192 zones in one
REPORT ZONES (~2 TiB+ at 256 MiB zones, i.e. any modern HM-SMR part)
overflows on the first iteration; the next batch is requested at a
wrapped LBA, the block layer rejects the backward jump, and sd truncates
the device to zero:

	sdX: Zone gap at sectors 18219532288..1039663104
	sdX: failed to revalidate zones

(524288 * 34751 = 18219532288, mod 2^32 = 1039663104.)

Mainline never shipped this: in the same series, patch 7 c976e588b34e
("scsi: sd: sd_zbc: Hide gap zones") rewrote the loop to advance per
descriptor from 64-bit device values. 5.15.y took patch 4 and the
intervening 628617be8968 but not c976e588b34e, keeping the broken
intermediate state.

Reverting is preferred over pulling in c976e588b34e: it is a ZBC-2
feature (gap zones, constant zone-starting-LBA granularity) adding ~130
lines across sd_zbc.c, sd.h and include/scsi/scsi_proto.h. It gains
nothing for the constant-zone-size HM-SMR drives 5.15.y serves, which
the restored sector_t advance already handles correctly.

The revert conflicted with bffcb7d6a287 (which renamed the field on the
advance line); resolved by keeping the restored "sector +=
sd_zbc_zone_sectors(sdkp) * i", which reads zone_info.zone_blocks via
logical_to_sectors() and is 64-bit. 93dde0bf2f39 stays in place and is
unaffected.

Signed-off-by: Simon Liebold <simonlie@amazon.de>
---
 drivers/scsi/sd_zbc.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
index 90d0f8ddd179c..d84a9c1d76c5a 100644
--- a/drivers/scsi/sd_zbc.c
+++ b/drivers/scsi/sd_zbc.c
@@ -223,7 +223,7 @@ int sd_zbc_report_zones(struct gendisk *disk, sector_t sector,
 			unsigned int nr_zones, report_zones_cb cb, void *data)
 {
 	struct scsi_disk *sdkp = scsi_disk(disk);
-	sector_t lba = sectors_to_logical(sdkp->device, sector);
+	sector_t capacity = logical_to_sectors(sdkp->device, sdkp->capacity);
 	unsigned int nr, i;
 	unsigned char *buf;
 	size_t offset, buflen = 0;
@@ -234,7 +234,7 @@ int sd_zbc_report_zones(struct gendisk *disk, sector_t sector,
 		/* Not a zoned device */
 		return -EOPNOTSUPP;
 
-	if (!sdkp->capacity)
+	if (!capacity)
 		/* Device gone or invalid */
 		return -ENODEV;
 
@@ -242,8 +242,9 @@ int sd_zbc_report_zones(struct gendisk *disk, sector_t sector,
 	if (!buf)
 		return -ENOMEM;
 
-	while (zone_idx < nr_zones && lba < sdkp->capacity) {
-		ret = sd_zbc_do_report_zones(sdkp, buf, buflen, lba, true);
+	while (zone_idx < nr_zones && sector < capacity) {
+		ret = sd_zbc_do_report_zones(sdkp, buf, buflen,
+				sectors_to_logical(sdkp->device, sector), true);
 		if (ret)
 			goto out;
 
@@ -261,7 +262,7 @@ int sd_zbc_report_zones(struct gendisk *disk, sector_t sector,
 			zone_idx++;
 		}
 
-		lba += sdkp->zone_info.zone_blocks * i;
+		sector += sd_zbc_zone_sectors(sdkp) * i;
 	}
 
 	ret = zone_idx;

base-commit: 0248c33e835ecbec3a591f93fdaae53f7b90a4d6
-- 
2.50.1


                 reply	other threads:[~2026-10-05 15:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261005150713.3919586-1-simonlie@amazon.de \
    --to=simonlie@amazon.de \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stable@vger.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

all inboxes | Powered by JetHome®