Re: [PATCH v6 17/40] scsi: mpt3sas: use 16-bits defined sense codes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Local variable 'rc' in _scsih_determine_disposition is declared static, causing a global data race.
--

commit 237624bf0d56187b272fd92abe88d5f7ffa6aef7
Author: Damien Le Moal <dlemoal@kernel.org>

scsi: mpt3sas: use 16-bits defined sense codes

Refactor the mpt3sas driver to replace all hard-coded additional sense
codes and additional sense code qualifiers with the enum values defined in
include/scsi/scsi_sense.h. This helps with code clarity as the sense codes
being processed are easier to test and self-documented.

> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 0e12009a87f62..085d4672db854 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c

[ ... ]

> @@ -7691,38 +7691,41 @@ _scsih_determine_disposition(struct MPT3SAS_ADAPTER *ioc,
>  
>  	if (check_sense) {
>  		_scsih_normalize_sense(transfer_packet->sense, &sense_info);
> -		if (sense_info.skey == UNIT_ATTENTION)
> +		if (sense_info.skey == UNIT_ATTENTION) {
>  			rc = DEVICE_RETRY_UA;

[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing 
issue with the 'rc' variable being assigned here. 

In drivers/scsi/mpt3sas/mpt3sas_scsih.c, _scsih_determine_disposition() 
declares 'rc' as a function-scope static variable:

        static enum device_responsive_state rc;

Because mpt3sas controllers use separate workqueue threads 
(firmware_event_thread) for each controller, systems with multiple HBAs 
can invoke _scsih_determine_disposition() concurrently. 

Since 'rc' is shared globally across all CPUs and controllers without 
locking, can one thread's assignment to 'rc' be overwritten by another 
thread before the function returns? 

Could this concurrent modification lead to returning an incorrect 
disposition (like DEVICE_READY instead of DEVICE_ERROR) and cause 
subsequent logic errors during SCSI device discovery or polling?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908090308.1085097-1-dlemoal@kernel.org?part=17