[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

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

[vince]

Hi Laurence,
Thanks for your review and for asking about the SANITIZE initiation.

I clarified the drives' history: SANITIZE was started under Linux 6.x
or earlier, and the machine was powered off before it completed.
When the drives were later connected to a Linux 7.x system, the HBA
detected them, but mpt3sas did not register them as SCSI devices.

I have now reproduced the regression with a separate Seagate ST600MP0005
600 GB SAS HDD, serial S7M0ER6F:

1. Linux 6.18.55 LTS: I started SANITIZE OVERWRITE and verified that
   TEST UNIT READY returned NOT READY (02/04/1B), with 0.07% progress.

2. Stock Linux 7.2.11 (unpatched mpt3sas): After rebooting, the HBA
   detected the disk's SAS address (0x5000c5008e53f8e5), but the driver
   repeatedly issued REPORT LUNS / TEST UNIT READY / START UNIT.
   After 145 discovery attempts and 146 START UNIT commands, the disk
   remained absent from both sd and sg device lists. This prevents users
   from monitoring SANITIZE progress and may cause them to mistake a
   healthy drive for a failed one.

3. Patched Linux 7.2.11: After another reboot, the driver correctly
   handled the 02/04/1B condition and immediately registered the same
   disk as /dev/sda (0 B) and /dev/sg0. READ CAPACITY still reported
   SANITIZE IN PROGRESS, and a subsequent REQUEST SENSE progress query
   showed 22.58%. The other SAS disk registered normally throughout.

This confirms that a drive already sanitizing at discovery time becomes
invisible with unpatched 7.2.11, whereas the patched driver registers
it without falsely treating the media as ready.

The controlled reproduction used reboots rather than a separate full
power-cycle test. The original drives had been powered off during
SANITIZE.

I have saved the kernel boot logs, driver build IDs, device inventories,
and the full 145-attempt trace. I can provide them if helpful.

Thanks again for the Reviewed-by!

Best regards,
Vincent YUE

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.