Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jeff Layton" <jlayton@kernel.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 2/2] scsi: mpt3sas: Time out delayed not-responding device blocks
Date: Fri, 06 Nov 2026 20:57:39 +0000	[thread overview]
Message-ID: <sashiko-outbox-202261@kernel.org> (raw)
In-Reply-To: <20261106-sas-abba-v3-2-571b854594aa@kernel.org>

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] scsi: mpt3sas: use-after-free of sdev->hostdata in unblock
  helpers
- [Medium] scsi: mpt3sas: race setting SDEV_OFFLINE outside block_lock
  on unblock failure
- [Medium] scsi: mpt3sas: _scsih_block_io_all_device() leaves sdevs
  blocked without deadline
--

commit ba9687a8025a542963a3bc4d91c8e8b094a21e74
Author: Jeff Layton <jlayton@kernel.org>

scsi: mpt3sas: Time out delayed not-responding device blocks

This commit adds a delayed work item and per-device deadline to release
delayed not-responding sdev blocks after the firmware's device missing
delay plus 30 seconds, preventing scans from deadlocking on sas_host->lock.

> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 60c9cf679a8a7..acdeece20140f 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c

[ ... ]

> @@ -3958,7 +3989,20 @@ _scsih_ublock_io_all_device(struct MPT3SAS_ADAPTER *ioc, u8 no_turs)
>  	int count = 0;
>  	u8 tr_method = 0;
>  	u8 tr_timeout = 30;
> +	unsigned long flags;
>  
> +	/* polling one device can outlast another's deadline */
> +	if (!no_turs && issue_scsi_cmd_to_bringup_drive) {
> +		shost_for_each_device(sdev, ioc->shost) {
> +			spin_lock_irqsave(&ioc->block_lock, flags);
> +			sas_device_priv_data = sdev->hostdata;
> +			if (sas_device_priv_data &&
> +			    sas_device_priv_data->sas_target &&
> +			    !sas_device_priv_data->sas_target->deleted)
> +				sas_device_priv_data->block_deadline = 0;
> +			spin_unlock_irqrestore(&ioc->block_lock, flags);
> +		}
> +	}
>  
>  	shost_for_each_device(sdev, ioc->shost) {
>  		sas_device_priv_data = sdev->hostdata;
> @@ -3975,10 +4019,18 @@ _scsih_ublock_io_all_device(struct MPT3SAS_ADAPTER *ioc, u8 no_turs)
>  		if ((no_turs) || (!issue_scsi_cmd_to_bringup_drive)) {
>  			sdev_printk(KERN_WARNING, sdev, "device_unblocked handle(0x%04x)\n",
>  				sas_device_priv_data->sas_target->handle);
> -			_scsih_internal_device_unblock(sdev, sas_device_priv_data);
> +			spin_lock_irqsave(&ioc->block_lock, flags);
> +			/* dnr_unblock_work may have released it */
> +			if (sas_device_priv_data->block)
> +				_scsih_internal_device_unblock(sdev,
> +				    sas_device_priv_data);
> +			spin_unlock_irqrestore(&ioc->block_lock, flags);
>  			continue;
>  		}
>  
> +		/* may have been blocked since the first pass */
> +		if (!_scsih_claim_block(ioc, sdev))
> +			continue;
>  		do {
>  			pcie_device = mpt3sas_get_pdev_by_handle(ioc, sas_target->handle);
>  			if (pcie_device && (!ioc->tm_custom_handling) &&
> @@ -3997,11 +4049,13 @@ _scsih_ublock_io_all_device(struct MPT3SAS_ADAPTER *ioc, u8 no_turs)
>  		} while ((rc == DEVICE_RETRY || rc == DEVICE_START_UNIT ||
>  		    rc == DEVICE_STOP_UNIT || rc == DEVICE_RETRY_UA)
>  			&& count++ < command_retry_count);
> +		spin_lock_irqsave(&ioc->block_lock, flags);
>  		sas_device_priv_data->block = 0;
>  		if (rc != DEVICE_READY)
>  			sas_device_priv_data->deleted = 1;
>  
>  		_scsih_internal_device_unblock(sdev, sas_device_priv_data);
> +		spin_unlock_irqrestore(&ioc->block_lock, flags);
>  
>  		if (rc != DEVICE_READY) {
>  			sdev_printk(KERN_WARNING, sdev, "%s: device_offlined,\n"

[Severity: High]
Can _scsih_ublock_io_all_device() and _scsih_ublock_io_device_wait() cause a
use-after-free on sas_device_priv_data and sas_target?

shost_for_each_device() only holds a reference on sdev, not sdev->hostdata.
When _scsih_dnr_unblock_work() unblocks an sdev that was blocked during a
concurrent sysfs scan and its probe fails in scsi_probe_and_add_lun(), or
when a device is removed via sysfs, __scsi_remove_device() calls
scsih_sdev_destroy(), which clears sdev->hostdata under ioc->block_lock and
frees sas_device_priv_data:

CPU0 (firmware_event_thread)      CPU1 (scan / device removal)
_scsih_ublock_io_all_device()
  sas_device_priv_data =
    sdev->hostdata;
  _scsih_claim_block(ioc, sdev)
  _scsih_wait_for_device_...()
                                  __scsi_remove_device(sdev)
                                    scsih_sdev_destroy(sdev)
                                      spin_lock_irqsave(&ioc->block_lock)
                                      sdev->hostdata = NULL;
                                      spin_unlock_irqrestore(&ioc->block_lock)
                                      kfree(sas_device_priv_data);
  spin_lock_irqsave(&ioc->block_lock)
  sas_device_priv_data->block = 0;  <-- use-after-free

Both functions also read sdev->hostdata and dereference
sas_device_priv_data->sas_target at the top of their second
shost_for_each_device() loops without holding ioc->block_lock, and in the
no_turs branch _scsih_ublock_io_all_device() takes ioc->block_lock and
accesses the cached sas_device_priv_data pointer without re-checking
sdev->hostdata.  Re-fetching sdev->hostdata (and sas_target) under
ioc->block_lock before each access and after the polling loop would avoid
touching freed hostdata.

> @@ -4060,24 +4114,30 @@ _scsih_ublock_io_device_wait(struct MPT3SAS_ADAPTER *ioc, u64 sas_address,
>  	u8 tr_timeout = 30;
>  	u8 tr_method = 0;
>  	int count = 0;
> +	unsigned long flags;
>  
>  	/* moving devices from SDEV_OFFLINE to SDEV_BLOCK */
>  	shost_for_each_device(sdev, ioc->shost) {
> +		spin_lock_irqsave(&ioc->block_lock, flags);
>  		sas_device_priv_data = sdev->hostdata;
>  		if (!sas_device_priv_data)
> -			continue;
> +			goto next;
>  		sas_target = sas_device_priv_data->sas_target;
>  		if (!sas_target)
> -			continue;
> +			goto next;
>  		if (sas_target->sas_address != sas_address ||
>  		    sas_target->port != port)
> -			continue;
> +			goto next;
> +		/* polling one device can outlast another's deadline */
> +		sas_device_priv_data->block_deadline = 0;
>  		if (sdev->sdev_state == SDEV_OFFLINE) {
>  			sas_device_priv_data->block = 1;
>  			sas_device_priv_data->deleted = 0;
>  			scsi_device_set_state(sdev, SDEV_RUNNING);
>  			scsi_internal_device_block_nowait(sdev);
>  		}
> +next:
> +		spin_unlock_irqrestore(&ioc->block_lock, flags);
>  	}
>  
>  	/* moving devices from SDEV_BLOCK to SDEV_RUNNING state */
> @@ -4091,7 +4151,7 @@ _scsih_ublock_io_device_wait(struct MPT3SAS_ADAPTER *ioc, u64 sas_address,
>  		if (sas_target->sas_address != sas_address ||
>  		    sas_target->port != port)
>  			continue;
> -		if (!sas_device_priv_data->block)
> +		if (!_scsih_claim_block(ioc, sdev))
>  			continue;
>  
>  		do {
> @@ -4129,10 +4189,12 @@ _scsih_ublock_io_device_wait(struct MPT3SAS_ADAPTER *ioc, u64 sas_address,
>  		    rc == DEVICE_STOP_UNIT || rc == DEVICE_RETRY_UA)
>  			&& count++ <= command_retry_count);
>  
> +		spin_lock_irqsave(&ioc->block_lock, flags);
>  		sas_device_priv_data->block = 0;
>  		if (rc != DEVICE_READY)
>  			sas_device_priv_data->deleted = 1;
>  		scsi_internal_device_unblock_nowait(sdev, SDEV_RUNNING);
> +		spin_unlock_irqrestore(&ioc->block_lock, flags);
>  
>  		if (rc != DEVICE_READY) {
>  			sdev_printk(KERN_WARNING, sdev,

[Severity: Medium]
When rc != DEVICE_READY in _scsih_ublock_io_device_wait() (and in
_scsih_ublock_io_all_device()), can dropping ioc->block_lock before calling
scsi_device_set_state(sdev, SDEV_OFFLINE) race with _scsih_block_io_device()?

CPU0 (firmware_event_thread)      CPU1 (<hardirq>)
_scsih_ublock_io_device_wait()
  spin_lock_irqsave(&ioc->block_lock)
  sas_device_priv_data->block = 0;
  scsi_internal_device_unblock_nowait(
    sdev, SDEV_RUNNING)
  spin_unlock_irqrestore(&ioc->block_lock)
                                  _scsih_block_io_device()
                                    spin_lock_irqsave(&ioc->block_lock)
                                    /* sdev_state is SDEV_RUNNING */
                                    _scsih_internal_device_block(sdev, ...)
                                    sas_device_priv_data->block_deadline = ...;
                                    spin_unlock_irqrestore(&ioc->block_lock)
  ...
  scsi_device_set_state(sdev,
    SDEV_OFFLINE)  <-- overwrites SDEV_BLOCK; queue stays stopped

Because sdev->sdev_state is SDEV_RUNNING while ioc->block_lock is dropped,
_scsih_block_io_device() does not see SDEV_OFFLINE and stops the request
queue, sets block = 1, and arms block_deadline.  CPU0 then sets
sdev->sdev_state to SDEV_OFFLINE with the queue still stopped (so
scsi_queue_rq() cannot fail queued I/O with BLK_STS_IOERR) and an active
block_deadline that will later transition the offline device back to
SDEV_RUNNING without a TUR check.  Setting SDEV_OFFLINE before releasing
ioc->block_lock would close this window.

[ ... ]

> @@ -4213,21 +4279,119 @@ _scsih_block_io_all_device(struct MPT3SAS_ADAPTER *ioc)
>  {
>  	struct MPT3SAS_DEVICE *sas_device_priv_data;
>  	struct scsi_device *sdev;
> +	unsigned long flags;
>  
>  	shost_for_each_device(sdev, ioc->shost) {
> +		spin_lock_irqsave(&ioc->block_lock, flags);
>  		sas_device_priv_data = sdev->hostdata;
>  		if (!sas_device_priv_data)
> -			continue;
> -		if (sas_device_priv_data->block)
> -			continue;
> +			goto next;
> +		if (sas_device_priv_data->block) {
> +			/* the caller unblocks it; dnr_unblock_work must not */
> +			sas_device_priv_data->block_deadline = 0;
> +			goto next;
> +		}
>  		if (sas_device_priv_data->ignore_delay_remove) {
>  			sdev_printk(KERN_INFO, sdev,
>  			"%s skip device_block for SES handle(0x%04x)\n",
>  			__func__, sas_device_priv_data->sas_target->handle);
> -			continue;
> +			goto next;
>  		}
>  		_scsih_internal_device_block(sdev, sas_device_priv_data);
> +next:
> +		spin_unlock_irqrestore(&ioc->block_lock, flags);
>  	}
> +}

[Severity: Medium]
Can _scsih_block_io_all_device() leave devices blocked with
block_deadline == 0 so that neither the caller nor _scsih_dnr_unblock_work()
unblocks them before device removal?

_scsih_block_io_all_device() blocks every sdev (or clears its
block_deadline) without checking sas_target->deleted, whereas its paired
_scsih_ublock_io_all_device() skips targets with sas_target->deleted set.
In addition, its caller _scsih_sas_broadcast_primitive_event() skips
_scsih_ublock_io_all_device() altogether when host recovery starts:

drivers/scsi/mpt3sas/mpt3sas_scsih.c:_scsih_sas_broadcast_primitive_event() {
    ...
	ioc->broadcast_aen_busy = 0;
	if (!ioc->shost_recovery)
		_scsih_ublock_io_all_device(ioc, 1);
	mutex_unlock(&ioc->tm_cmds.mutex);
}

After host reset, _scsih_remove_unresponding_devices() runs on
firmware_event_thread and removes unresponding devices (taking
sas_host->lock and shost->scan_mutex) before it reaches
_scsih_ublock_io_all_device(ioc, 0).  If a concurrent sysfs scan holds
sas_host->lock and waits on I/O to one of these sdevs whose block_deadline
was cleared to 0, _scsih_dnr_unblock_work() will not unblock it and the scan
deadlock recurs.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-sas-abba-v3-0-571b854594aa@kernel.org?part=2

      reply	other threads:[~2026-11-06 20:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 20:29 [PATCH v3 0/2] scsi: mpt3sas: Fix delayed not-responding sdev block handling Jeff Layton
2026-11-06 20:29 ` [PATCH v3 1/2] scsi: mpt3sas: Serialize interrupt-time sdev block with hostdata teardown Jeff Layton
2026-11-06 20:29 ` [PATCH v3 2/2] scsi: mpt3sas: Time out delayed not-responding device blocks Jeff Layton
2026-11-06 20:57   ` sashiko-bot [this message]

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-202261@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=jlayton@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox