All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Brian Bunker" <brian@purestorage.com>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v7 1/5] scsi: core: Protect INQUIRY sysfs attributes with mutex
Date: Wed, 14 Oct 2026 22:12:56 +0000	[thread overview]
Message-ID: <sashiko-outbox-171947@kernel.org> (raw)
In-Reply-To: <20261014220014.94330-2-brian@purestorage.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: sysfs modalias and uevent missing inquiry_mutex protection
--

commit 81f6a8643e20a98783acfb264a3488a0b0ad95ac
Author: Brian Bunker <brian@purestorage.com>

scsi: core: Protect INQUIRY sysfs attributes with mutex
    
All INQUIRY-derived sysfs attributes (type, scsi_level, vendor, model,
rev, cdl_supported, and the binary inquiry attribute) read data that
can be updated during device rescan. These reads must be protected
against concurrent updates.

> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index fe54792ed69e4..a20707f6f1ac7 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -638,21 +638,30 @@ sdev_show_##field (struct device *dev, struct device_attribute *attr,	\
>  
>  /*
>   * sdev_rd_attr: macro to create a function and attribute variable for a
> - * read only field.
> + * read-only field. inquiry_mutex protects INQUIRY-derived fields against
> + * concurrent updates during device rescan.
>   */
>  #define sdev_rd_attr(field, format_string)				\
> -	sdev_show_function(field, format_string)			\
> -static DEVICE_ATTR(field, S_IRUGO, sdev_show_##field, NULL);
> +static ssize_t								\
> +sdev_show_##field(struct device *dev, struct device_attribute *attr,	\
> +		  char *buf)						\
> +{									\
> +	struct scsi_device *sdev = to_scsi_device(dev);			\
> +									\
> +	guard(mutex)(&sdev->inquiry_mutex);				\
> +	return sysfs_emit(buf, format_string, sdev->field);		\
> +}									\
> +static DEVICE_ATTR(field, S_IRUGO, sdev_show_##field, NULL)
>  
>  /*
>   * Create the actual show/store functions and data structures.
>   */
> -sdev_rd_attr (type, "%d\n");
> -sdev_rd_attr (scsi_level, "%d\n");
> -sdev_rd_attr (vendor, "%.8s\n");
> -sdev_rd_attr (model, "%.16s\n");
> -sdev_rd_attr (rev, "%.4s\n");
> -sdev_rd_attr (cdl_supported, "%d\n");
> +sdev_rd_attr(type, "%d\n");

[Severity: Medium]
The commit states all INQUIRY-derived sysfs attributes, including type, must
be protected by inquiry_mutex against concurrent updates.

However, shouldn't sdev_show_modalias() and scsi_bus_uevent() also be updated?
They both read sdev->type locklessly to construct the modalias string:

drivers/scsi/scsi_sysfs.c:sdev_show_modalias() {
    ...
    sdev = to_scsi_device(dev);
    return snprintf (buf, 20, SCSI_DEVICE_MODALIAS_FMT "\n", sdev->type);
}

drivers/scsi/scsi_sysfs.c:scsi_bus_uevent() {
    ...
    sdev = to_scsi_device(dev);
    add_uevent_var(env, "MODALIAS=" SCSI_DEVICE_MODALIAS_FMT, sdev->type);
    ...
}

Can concurrent device rescans cause these functions to read an inconsistent
or transient sdev->type?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014220014.94330-1-brian@purestorage.com?part=1

  reply	other threads:[~2026-10-14 22:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 22:00 [PATCH v7 0/5] scsi: Refresh INQUIRY data and reprobe on rescan Brian Bunker
2026-10-14 22:00 ` [PATCH v7 1/5] scsi: core: Protect INQUIRY sysfs attributes with mutex Brian Bunker
2026-10-14 22:12   ` sashiko-bot [this message]
2026-10-14 22:00 ` [PATCH v7 2/5] scsi: core: Add scsi_update_inquiry_data() for updating INQUIRY data Brian Bunker
2026-10-14 22:00 ` [PATCH v7 3/5] scsi: core: Refactor scsi_add_lun() to use scsi_update_inquiry_data() Brian Bunker
2026-10-14 22:00 ` [PATCH v7 4/5] scsi: core: Add device reprobe support to scsi_rescan_device() Brian Bunker
2026-10-14 22:17   ` sashiko-bot
2026-10-14 22:00 ` [PATCH v7 5/5] scsi: core: Handle reprobe for existing devices during SCSI scan Brian Bunker

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=sashiko-outbox-171947@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=brian@purestorage.com \
    --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.