[PATCH] scsi: mpt3sas: Register devices during SANITIZE

[PATCH] scsi: mpt3sas: Register devices during SANITIZE

[vince]

A SAS disk being sanitized responds to TEST UNIT READY with NOT
READY, ASC 0x04, ASCQ 0x1b. mpt3sas discovery maps this sense to
DEVICE_START_UNIT and issues START UNIT repeatedly. The drive stays
NOT READY until the sanitize operation completes, causing discovery
to exhaust its retry budget and decline SCSI device registration.

Allow registration only for the SANITIZE IN PROGRESS sense, so sd/sg
can expose the target while retaining its actual NOT READY state.
All other sense dispositions are unchanged.

On an LSI SAS3008 with an HGST HUH728080AL4200, unpatched Linux
7.2.11 retried discovery 145 times without registering the device.
Linux 6.18.55 registered the same sanitizing drive. With the
equivalent 7.2.11 fix the disk registered as /dev/sda (0 B) and
/dev/sg0 while TEST UNIT READY still reported 02/04/1b and 47.32%
SANITIZE progress. Another SAS drive continued to enumerate.

This updated variant uses the named 0x041b sense constant introduced
in newer kernels. It passed static review on the current SCSI
for-next branch but has not been independently boot-tested there.

Fixes: aee682fad6cd ("scsi: mpt3sas: Improve device discovery and readiness handling for slow devices")
Assisted-by: LLM
Signed-off-by: Vincent YUE <vince@palmit.com.au>
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 085d4672d..a77bbc3d2 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -7700,7 +7700,9 @@ _scsih_determine_disposition(struct MPT3SAS_ADAPTER *ioc,
 				u16 scode = scsi_sense_code(sense_info.asc,
 							    sense_info.ascq);
 
-				if (scode ==
+				if (scode == LU_NOT_READY_SANITIZE_IN_PROGRESS)
+					rc = DEVICE_READY;
+				else if (scode ==
 				    LU_NOT_READY_MANUAL_INTERVENTION_REQUIRED ||
 				    scode ==
 				    LU_NOT_ACCESSIBLE_TARGET_PORT_IN_STANDBY_STATE ||
-- 
2.56.0


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material.

Re: [PATCH] scsi: mpt3sas: Register devices during SANITIZE

[Laurence Oberman]

On Wed, 2026-10-21 at 07:08 +1000, vince@palmit.com.au wrote:
> A SAS disk being sanitized responds to TEST UNIT READY with NOT
> READY, ASC 0x04, ASCQ 0x1b. mpt3sas discovery maps this sense to
> DEVICE_START_UNIT and issues START UNIT repeatedly. The drive stays
> NOT READY until the sanitize operation completes, causing discovery
> to exhaust its retry budget and decline SCSI device registration.
> 
> Allow registration only for the SANITIZE IN PROGRESS sense, so sd/sg
> can expose the target while retaining its actual NOT READY state.
> All other sense dispositions are unchanged.
> 
> On an LSI SAS3008 with an HGST HUH728080AL4200, unpatched Linux
> 7.2.11 retried discovery 145 times without registering the device.
> Linux 6.18.55 registered the same sanitizing drive. With the
> equivalent 7.2.11 fix the disk registered as /dev/sda (0 B) and
> /dev/sg0 while TEST UNIT READY still reported 02/04/1b and 47.32%
> SANITIZE progress. Another SAS drive continued to enumerate.
> 
> This updated variant uses the named 0x041b sense constant introduced
> in newer kernels. It passed static review on the current SCSI
> for-next branch but has not been independently boot-tested there.
> 
> Fixes: aee682fad6cd ("scsi: mpt3sas: Improve device discovery and
> readiness handling for slow devices")
> Assisted-by: LLM
> Signed-off-by: Vincent YUE <vince@palmit.com.au>
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 085d4672d..a77bbc3d2 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -7700,7 +7700,9 @@ _scsih_determine_disposition(struct
> MPT3SAS_ADAPTER *ioc,
>  				u16 scode =
> scsi_sense_code(sense_info.asc,
>  							   
> sense_info.ascq);
>  
> -				if (scode ==
> +				if (scode ==
> LU_NOT_READY_SANITIZE_IN_PROGRESS)
> +					rc = DEVICE_READY;
> +				else if (scode ==
>  				   
> LU_NOT_READY_MANUAL_INTERVENTION_REQUIRED ||
>  				    scode ==
>  				   
> LU_NOT_ACCESSIBLE_TARGET_PORT_IN_STANDBY_STATE ||
> --
> 2.56.0
> 
> 
Hello

The patch looks good. I am curious, though, how the drive got into the
sanitize state before it was registered. Was SANITIZE issued while the
drive was registered under 6.18 (or via mpt3sas passthrough), followed
by a reboot into 7.2.11? Or did the drive come up already sanitizing,
for example after a power cycle part way through an operation started
elsewhere? Since a sanitize persists across power-on, the second case
would mean a drive in this state is simply invisible on the unpatched
kernel, which strengthens the case for the fix.

Reviewed-by: Laurence Oberman loberman@redhat.com