All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v4 8/9] scsi: sd_zbc: always revalidate zones for disks supporting head depopulation
Date: Fri, 9 Oct 2026 11:34:53 +0200	[thread overview]
Message-ID: <01883533-837b-47bd-93df-aba3fbda997e@kernel.org> (raw)
In-Reply-To: <sashiko-outbox-165171@kernel.org>

On 2026/10/09 11:32, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] scsi: sd: data race on struct scsi_disk bitfields can clobber WCE or modify_zones_supported
> --
> 
> commit a445da75935ac3ec4cee9fc525679769cf828446
> Author: Damien Le Moal <dlemoal@kernel.org>
> 
> scsi: sd_zbc: always revalidate zones for disks supporting head depopulation
> 
> This commit introduces a new check for ZBC devices that support data preserving
> head depopulation to ensure zone conditions are properly revalidated. It adds
> a new modify_zones_supported bitfield to struct scsi_disk and sets it during
> sd_zbc_read_zones(). The flag is then used to skip or perform zone revalidation
> depending on the disk's support for this feature.
> 
>> diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
>> index 574af82430169..6a72371fee786 100644
>> --- a/drivers/scsi/sd.h
>> +++ b/drivers/scsi/sd.h
>> @@ -156,6 +156,7 @@ struct scsi_disk {
>>  	unsigned	ignore_medium_access_errors : 1;
>>  	unsigned	rscs : 1; /* reduced stream control support */
>>  	unsigned	use_atomic_write_boundary : 1;
>> +	unsigned	modify_zones_supported : 1;
>>  };
>>  #define to_scsi_disk(obj) container_of(obj, struct scsi_disk, disk_dev)
> 
> [ ... ]
> 
>> diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
>> index 8cbf171e6fabf..1bf5f7ea0d9c5 100644
>> --- a/drivers/scsi/sd_zbc.c
>> +++ b/drivers/scsi/sd_zbc.c
> [ ... ]
>> @@ -620,6 +641,9 @@ int sd_zbc_read_zones(struct scsi_disk *sdkp, struct queue_limits *lim,
>>  	if (ret != 0)
>>  		goto err;
>>  
>> +	/* Check if REMOVE ELEMENT AND MODIFY ZONES is supported. */
>> +	sdkp->modify_zones_supported = sd_zbc_check_modify_zones(sdkp, buf);
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> [Severity: High]
> Does this bitfield assignment introduce a data race that can silently corrupt
> neighboring bitfields like WCE?

Maybe... But this is not a new issue. All "flags" of a SCSI disks are defined as
"unsigned int :1" bits. Everything should be rewritten to use a proper unsigne
long bitfield with bit manipulation functions. So I am not going to fix that here.


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2026-10-09  9:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  9:09 [PATCH v4 0/9] Add support for storage element depopulation Damien Le Moal
2026-10-09  9:09 ` [PATCH v4 1/9] block: introduce disk_zone_is_offline() Damien Le Moal
2026-10-12 12:04   ` Christoph Hellwig
2026-10-09  9:09 ` [PATCH v4 2/9] block: refactor blk_revalidate_disk_zones() Damien Le Moal
2026-10-12 12:04   ` Christoph Hellwig
2026-10-09  9:09 ` [PATCH v4 3/9] block: introduce storage element management Damien Le Moal
2026-10-09  9:24   ` sashiko-bot
2026-10-09  9:09 ` [PATCH v4 4/9] block: add storage element management ioctls Damien Le Moal
2026-10-09  9:28   ` sashiko-bot
2026-10-09  9:09 ` [PATCH v4 5/9] zloop: add storage element emulation Damien Le Moal
2026-10-09  9:21   ` sashiko-bot
2026-10-09  9:09 ` [PATCH v4 6/9] zloop: add degrade_element control command Damien Le Moal
2026-10-09  9:09 ` [PATCH v4 7/9] scsi: sd: fail read commands to offline zones early Damien Le Moal
2026-10-09  9:09 ` [PATCH v4 8/9] scsi: sd_zbc: always revalidate zones for disks supporting head depopulation Damien Le Moal
2026-10-09  9:32   ` sashiko-bot
2026-10-09  9:34     ` Damien Le Moal [this message]
2026-10-09  9:09 ` [PATCH v4 9/9] scsi: sd_zbc: define storage element management operations Damien Le Moal
2026-10-09  9:28   ` sashiko-bot

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=01883533-837b-47bd-93df-aba3fbda997e@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.