From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794754233; b=Z9HcasIfcm4iEGfqUvoFHdoNhiyPjIOgg3SV1y+0O40EdedYAQfwRCcqkramOsWZp/OV xbP9AeBBGrJNrC8C+gzes6wU8elFYxo3iLHW2sHLieXG6+XdHQd5mHjaptUVh+KW/OdIf IZgrg5PPe/NfmTRTUtdlpLyG72OJED8+Xn7Bm32o+gHOGT3Ej6jPzsDiHZMCY9KyREr8T di9LBjmo+exz4H++VQXI2AiCiggfIr4pWbDnIkYXmJjjVsOBMmhwJ84Q8gHr8Gn/5NDSL GRUMigb1rb+YebCaUY7npWT8OCMPmct/yLi9cebm4AnVkVor7PsRvGNkHO/lmVct9zg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794754233; h=Received:DKIM-Signature:From:To:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=bVr5tuS7xh2PYiaNEswRMPU76wRqKv1igzs8AyprowU=; b=z+sVsewa4SK2x7zwj9r0EfA5efkhwfRXs4VDM9FKDhTIaHDAlw+I0TwS5NxoJg6DzrZ3 cI9oHMfNwGjHQkLgMIn1Dmqh/adqBKr5Syy6AI7Y7Fmm864yFuAXHvNZTaLDtoh7UsSdJ l/BucJXO1bVvBeTAmpG1yVEARddS+ZbMTbNk3HJ4ipMxCN6tSYLYYr4HYSDFaTtHI5Hmr gpWZBOCzZa+V7a+P0pbdOhEQZ5m+877auj5jDorNzBBCNXtI+oGWQfktDuu7SduS2mV0g pvA3/78oF1oxD5gTvW9+i6tT2K6A85czBRFxmY3dRPjJmwL2ckacRAcIPJ5OPaussXg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=jrncKwXr; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDB47606A32E; Sun, 15 Nov 2026 14:50:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=jrncKwXr Received: by smtp.kernel.org (Postfix) with ESMTPSA id E48271F000C4; Sun, 15 Nov 2026 14:50:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794754233; bh=bVr5tuS7xh2PYiaNEswRMPU76wRqKv1igzs8AyprowU=; h=From:To:Subject:Date:In-Reply-To:References; b=jrncKwXrzy1LXL2zTEJFIizOpMUTCEgYnD9ZXaR36yF74TvxxbyPqbKSPFuytggsY DtMCIXvv+4ffiS9OP8bVI6wFTyeuHG6R37ulYVNGCcfFitFBjJSauFezpAPfki6Klo JJzWrKE5ndfxNiORn/D4IWH84z6WtfS2Qi6G9hkvUbvU/83WHLaSLgnxA6YhITDEhe 0zp+QMfFZFhd4z4FZyaAhw7uVC0Sv+AH4vquNq6pCU/a6kOaw5yLfTt6DE2YehqpML EdBvE7ZxgtT0n2MnDzm0uphTS3AhLTgYj9mmwOJr1f/bwXwdSuioipLBRZxJLEBPy4 G36yrbTyrtAZA== From: Damien Le Moal To: Jens Axboe , linux-block@vger.kernel.org, Christoph Hellwig , linux-scsi@vger.kernel.org, "Martin K . Petersen" Subject: [PATCH v9 13/13] scsi: sd: fail read commands to offline zones early Date: Sun, 15 Nov 2026 23:50:15 +0900 Message-ID: <20261115145015.938426-14-dlemoal@kernel.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261115145015.938426-1-dlemoal@kernel.org> References: <20261115145015.938426-1-dlemoal@kernel.org> X-Mailing-List: linux-scsi@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Issuing read commands to offline zones of a ZBC disk will result in failures. So do not issue such command and fail them early in sd_setup_read_write_cmnd(). This change also checks write commands, which is fine but should actually never happen as the block layer zone write plugging code already fails write BIOs to offline zones early in the submission path. As the code comment explains, since disk_zone_is_offline() uses the block layer cached zone condition, this is inherently racy with zone revalidation updating the zone condition. However, this will never prevent valid read operations as the only case where we could proceed is if the read is received after a restoration of the disk storage element completes but before the zones are revalidated. And in that case, all zones are empty and thus have no data to read. Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Hannes Reinecke --- drivers/scsi/sd.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 34b44d72b2b7..8b1c05de541d 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -1424,7 +1424,8 @@ static blk_status_t sd_setup_read_write_cmnd(struct scsi_cmnd *cmd) { struct request *rq = scsi_cmd_to_rq(cmd); struct scsi_device *sdp = cmd->device; - struct scsi_disk *sdkp = scsi_disk(rq->q->disk); + struct gendisk *disk = rq->q->disk; + struct scsi_disk *sdkp = scsi_disk(disk); sector_t lba = sectors_to_logical(sdp, blk_rq_pos(rq)); sector_t threshold; unsigned int nr_blocks = sectors_to_logical(sdp, blk_rq_sectors(rq)); @@ -1456,6 +1457,23 @@ static blk_status_t sd_setup_read_write_cmnd(struct scsi_cmnd *cmd) goto fail; } + /* + * The block layer already prevents writes to offline zones of zoned + * block devices. But there are no checks for reads, so check this here. + * Since disk_zone_is_offline() uses the block layer cached zone + * condition, this is inherently racy with zone revalidation updating + * the zone condition. However, this will never prevent valid read + * operations as the only case where we could proceed is if the read is + * received after a restoration of the disk storage element completes + * but before the zones are revalidated. And in that case, all zones are + * empty and thus have no data to read. + * Note that we are quiet about the error (no message) to avoid flooding + * the kernel log. + */ + if (sdkp->device->type == TYPE_ZBC && + disk_zone_is_offline(disk, blk_rq_pos(rq))) + goto fail; + /* * Some SD card readers can't handle accesses which touch the * last one or two logical blocks. Split accesses as needed. -- 2.56.0