Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 06/17] scsi-multipath: clear path when device is blocked
Date: Mon, 6 Jul 2026 16:04:26 +0100	[thread overview]
Message-ID: <e99a1f34-af9f-4bc3-b933-4ddf00eba057@oracle.com> (raw)
In-Reply-To: <20260703113225.D312B1F000E9@smtp.kernel.org>

On 03/07/2026 12:32, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> 
> New issues:
> - [Critical] Unsafe lockless access to `scsi_mpath_head` in `scsi_mpath_dev_clear_path` races with device removal, causing a NULL pointer dereference or Use-After-Free.
> - [High] Adding a blocking synchronization call to the `nowait` context of `__scsi_internal_device_block_nowait` violates non-blocking guarantees.
> - [High] Publishing `sdev->scsi_mpath_dev` before `scsi_mpath_head` is initialized leads to NULL pointer dereferences during concurrent block requests.
> 
> Pre-existing issues:
> - [High] The error path in `scsi_mpath_alloc_head()` double-frees the `scsi_mpath_head` structure and its associated resources.
> - [High] The error path for `device_add()` failure in `scsi_mpath_dev_alloc()` causes a NULL pointer dereference and an invalid `device_unregister()`.
> --
> 
> commit 848d562af61faa57ddead6bc3e5e7a75ce63ea4e
> Author: John Garry <john.g.garry@oracle.com>
> Subject: scsi-multipath: clear path when device is blocked
> 
> This patch adds scsi_mpath_dev_clear_path() to clear a device path when it
> becomes blocked. It updates __scsi_internal_device_block_nowait() to call
> this new function when a path is available.
> 
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index daeb3693fe559..3c493068adb98 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
> [ ... ]
>> @@ -2923,6 +2924,8 @@ EXPORT_SYMBOL(scsi_target_resume);
>>   
>>   static int __scsi_internal_device_block_nowait(struct scsi_device *sdev)
>>   {
>> +	if (sdev->scsi_mpath_dev)
> 
> [Severity: High]
> Does this early access race with device probe?
> 
> If scsi_multipath_sdev_init() publishes sdev->scsi_mpath_dev before
> allocating scsi_mpath_head, could an asynchronous block request see this as
> true and invoke scsi_mpath_dev_clear_path(), leading to a NULL pointer
> dereference on the head?

this should not be a problem, but I will change to alloc head before 
publishing sdev->scsi_mpath_dev

> 
>> +		scsi_mpath_dev_clear_path(sdev->scsi_mpath_dev);
>>   	if (scsi_device_set_state(sdev, SDEV_BLOCK))
>>   		return scsi_device_set_state(sdev, SDEV_CREATED_BLOCK);
>>   
>> diff --git a/drivers/scsi/scsi_multipath.c b/drivers/scsi/scsi_multipath.c
>> index ca4ab720c19af..0f3f3f9fa5fae 100644
>> --- a/drivers/scsi/scsi_multipath.c
>> +++ b/drivers/scsi/scsi_multipath.c
> [ ... ]
>> @@ -113,6 +113,17 @@ static ssize_t scsi_mpath_device_vpd_id_show(struct device *dev,
>>   }
>>   static DEVICE_ATTR(vpd_id, S_IRUGO, scsi_mpath_device_vpd_id_show, NULL);
>>   
>> +void scsi_mpath_dev_clear_path(struct scsi_mpath_device *scsi_mpath_dev)
>> +{
>> +	struct mpath_device *mpath_device = &scsi_mpath_dev->mpath_device;
>> +	struct scsi_mpath_head *scsi_mpath_head = scsi_mpath_dev->scsi_mpath_head;
> 
> [Severity: Critical]
> Is this lockless access safe against concurrent device removal?
> 
> If scsi_mpath_remove_head() drops the head reference locklessly and sets:
>      scsi_mpath_dev->scsi_mpath_head = NULL;
> 
> Could a concurrent event hitting __scsi_internal_device_block_nowait()
> unconditionally call this and blindly dereference the NULL or freed
> scsi_mpath_head?

this should not happen as the sdev should be nearly removed when the 
scsi mpath head reference is put

> 
>> +	struct mpath_head *mpath_head = &scsi_mpath_head->mpath_head;
>> +
>> +	if (mpath_clear_current_path(mpath_device))
>> +		mpath_synchronize(mpath_head);
> 
> [Severity: High]
> Does this introduce a sleeping call into a nowait context?
> 
> __scsi_internal_device_block_nowait() is designed not to sleep to preserve
> batching optimizations. Since mpath_synchronize() typically sleeps to wait
> for grace periods or draining I/O, will calling it here break those
> optimizations or cause scheduling while atomic panics?

I need to check that

> 
>> +}
>> +EXPORT_SYMBOL_GPL(scsi_mpath_dev_clear_path);

  reply	other threads:[~2026-07-06 15:04 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 10:33 [PATCH v3 00/17] Native SCSI multipath support John Garry
2026-07-03 10:33 ` [PATCH v3 01/17] scsi-multipath: introduce basic SCSI device support John Garry
2026-07-03 10:53   ` sashiko-bot
2026-07-06 14:39     ` John Garry
2026-07-03 10:33 ` [PATCH v3 02/17] scsi-multipath: introduce scsi_device head structure John Garry
2026-07-03 10:49   ` sashiko-bot
2026-07-06 14:45     ` John Garry
2026-07-03 10:33 ` [PATCH v3 03/17] scsi-multipath: provide sysfs link from to scsi_device John Garry
2026-07-03 11:04   ` sashiko-bot
2026-07-03 10:33 ` [PATCH v3 04/17] scsi-multipath: support iopolicy John Garry
2026-07-03 11:10   ` sashiko-bot
2026-07-06 14:49     ` John Garry
2026-07-03 10:33 ` [PATCH v3 05/17] scsi-multipath: clone each bio John Garry
2026-07-03 11:26   ` sashiko-bot
2026-07-06 14:53     ` John Garry
2026-07-03 10:33 ` [PATCH v3 06/17] scsi-multipath: clear path when device is blocked John Garry
2026-07-03 11:32   ` sashiko-bot
2026-07-06 15:04     ` John Garry [this message]
2026-07-03 10:33 ` [PATCH v3 07/17] scsi-multipath: failover handling John Garry
2026-07-03 11:40   ` sashiko-bot
2026-07-06 15:32     ` John Garry
2026-07-03 10:33 ` [PATCH v3 08/17] scsi-multipath: provide callbacks for path state John Garry
2026-07-03 11:49   ` sashiko-bot
2026-07-06 15:38     ` John Garry
2026-07-03 10:33 ` [PATCH v3 09/17] scsi-multipath: add scsi_mpath_{start,end}_request() John Garry
2026-07-03 11:53   ` sashiko-bot
2026-07-06 15:44     ` John Garry
2026-07-03 10:33 ` [PATCH v3 10/17] scsi-multipath: block PR commands John Garry
2026-07-03 12:03   ` sashiko-bot
2026-07-03 10:33 ` [PATCH v3 11/17] scsi-multipath: add delayed disk removal support John Garry
2026-07-03 12:08   ` sashiko-bot
2026-07-06 15:49     ` John Garry
2026-07-03 10:33 ` [PATCH v3 12/17] scsi: sd: add multipath disk class John Garry
2026-07-03 10:33 ` [PATCH v3 13/17] scsi: sd: support multipath disk John Garry
2026-07-03 12:24   ` sashiko-bot
2026-07-07  9:18     ` John Garry
2026-07-03 10:33 ` [PATCH v3 14/17] scsi: sd: add multipath disk attr groups John Garry
2026-07-03 12:25   ` sashiko-bot
2026-07-07  9:09     ` John Garry
2026-07-03 10:34 ` [PATCH v3 15/17] scsi: sd: add mpath_dev file John Garry
2026-07-03 12:43   ` sashiko-bot
2026-07-06 15:56     ` John Garry
2026-07-03 10:34 ` [PATCH v3 16/17] scsi: sd: add mpath_numa_nodes dev attribute John Garry
2026-07-03 12:44   ` sashiko-bot
2026-07-06 15:57     ` John Garry
2026-07-03 10:34 ` [PATCH v3 17/17] scsi: sd: add mpath_queue_depth " John Garry
2026-07-03 12:57   ` sashiko-bot
2026-07-06 15:59     ` John Garry

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=e99a1f34-af9f-4bc3-b933-4ddf00eba057@oracle.com \
    --to=john.g.garry@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox