Linux s390 Architecture development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Damien Le Moal" <dlemoal@kernel.org>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	cassel@kernel.org, linux-s390@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	linux-ide@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
	dlemoal@kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v5 16/40] scsi: device_handlers: alua: use 16-bits defined sense codes
Date: Mon, 07 Sep 2026 02:57:36 +0000	[thread overview]
Message-ID: <20260907025736.CA7021F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260907024343.1046387-17-dlemoal@kernel.org>

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

Pre-existing issues:
- [High] Uninitialized stack memory `sense_hdr` is unconditionally evaluated in `alua_tur()` if `scsi_test_unit_ready()` fails locally.
--

commit 8e77c706432e156d81e3b3bd7cdc9af0c2b4cc23
Author: Damien Le Moal <dlemoal@kernel.org>

scsi: device_handlers: alua: use 16-bits defined sense codes

This commit refactors the SCSI ALUA device handler driver to use the 16-bit
sense_code field of struct scsi_sense_hdr. It replaces hard-coded ASC and
ASCQ values with enum constants from include/scsi/scsi_sense.h to improve
code clarity. No functional change is intended.

> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c
> index d81ec47a71402..87ac0a6d63e54 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c

[ ... ]

> @@ -517,12 +499,12 @@ static int alua_tur(struct scsi_device *sdev)
>  				      ALUA_FAILOVER_RETRIES, &sense_hdr);
>  	if ((sense_hdr.sense_key == NOT_READY ||
>  	     sense_hdr.sense_key == UNIT_ATTENTION) &&
> -	    sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a)
> +	    sense_hdr.sense_code ==
> +	    LU_NOT_ACCESSIBLE_ASYMMETRIC_ACCESS_STATE_TRANSITION)

[Severity: High]
This is a pre-existing issue, but does this evaluate uninitialized stack
memory if scsi_test_unit_ready() fails locally?

Looking at alua_tur() in drivers/scsi/device_handler/scsi_dh_alua.c:

static int alua_tur(struct scsi_device *sdev)
{
        struct scsi_sense_hdr sense_hdr;
        int retval;

        retval = scsi_test_unit_ready(sdev, ALUA_FAILOVER_TIMEOUT * HZ,
                                      ALUA_FAILOVER_RETRIES, &sense_hdr);

The sense_hdr variable is declared on the stack without initialization. If the
underlying request allocation fails or the queue is dying,
scsi_test_unit_ready() will return a negative error code (e.g., -ENODEV or
-ENOMEM) without zeroing or populating the sense_hdr buffer.

This condition then unconditionally evaluates sense_hdr.sense_key and
sense_hdr.sense_code before checking if retval indicates a local failure.

If alua_tur() is called from a multipath workqueue thread immediately after a
previous successful ALUA state transition check on another LUN, the stack
memory will identically retain the previous struct's values. This
uninitialized read could match the condition perfectly, causing alua_tur() to
wrongly return SCSI_DH_RETRY instead of the expected SCSI_DH_IO for a local
error, severely delaying multipath failover.

>  		return SCSI_DH_RETRY;
> -	else if (retval)
> +	if (retval)
>  		return SCSI_DH_IO;
> -	else
> -		return SCSI_DH_OK;
> +	return SCSI_DH_OK;
>  }

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

  reply	other threads:[~2026-09-07  2:57 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07  2:43 [PATCH v5 00/40] Use defined 16-bits ASC/ASCQ combinations Damien Le Moal
2026-09-07  2:43 ` [PATCH v5 01/40] scsi: define all additional sense codes and their qualifiers Damien Le Moal
2026-09-07  3:14   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 02/40] scsi: constants: use defined sense codes Damien Le Moal
2026-09-07  2:51   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 03/40] scsi: constants: rename internal struct field names Damien Le Moal
2026-09-07  2:48   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 04/40] scsi: rename sense field of struct scsi_failure Damien Le Moal
2026-09-07  2:54   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 05/40] scsi: prepare for using 16-bits defined sense codes Damien Le Moal
2026-09-07  2:54   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 06/40] scsi: use struct scsi_sense_hdr to log sense keys and codes Damien Le Moal
2026-09-07  2:52   ` sashiko-bot
2026-09-07 20:05   ` Bart Van Assche
2026-09-08  0:32     ` Damien Le Moal
2026-09-07  2:43 ` [PATCH v5 07/40] scsi: core: use 16-bits defined sense codes Damien Le Moal
2026-09-07  2:54   ` sashiko-bot
2026-09-07 20:03   ` Bart Van Assche
2026-09-08  0:32     ` Damien Le Moal
2026-09-07  2:43 ` [PATCH v5 08/40] scsi: sd: " Damien Le Moal
2026-09-07  3:11   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 09/40] scsi: sr: " Damien Le Moal
2026-09-07  2:54   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 10/40] scsi: ses: " Damien Le Moal
2026-09-07  2:56   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 11/40] scsi: ch: " Damien Le Moal
2026-09-07  2:54   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 12/40] scsi: st: " Damien Le Moal
2026-09-07  2:57   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 13/40] scsi: device_handlers: hp_sw: " Damien Le Moal
2026-09-07  2:50   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 14/40] scsi: device_handlers: rdac: " Damien Le Moal
2026-09-07  2:52   ` sashiko-bot
2026-09-07 14:11   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 15/40] scsi: device_handlers: emc: " Damien Le Moal
2026-09-07  3:02   ` sashiko-bot
2026-09-07 14:13   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 16/40] scsi: device_handlers: alua: " Damien Le Moal
2026-09-07  2:57   ` sashiko-bot [this message]
2026-09-07 14:21   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 17/40] scsi: mpt3sas: " Damien Le Moal
2026-09-07  2:55   ` sashiko-bot
2026-09-07 14:28   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 18/40] scsi: mpi3mr: " Damien Le Moal
2026-09-07  2:55   ` sashiko-bot
2026-09-07 14:30   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 19/40] scsi: 3w-xxxx: " Damien Le Moal
2026-09-07  2:58   ` sashiko-bot
2026-09-07 14:39   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 20/40] scsi: leapraid: " Damien Le Moal
2026-09-07  3:00   ` sashiko-bot
2026-09-07 14:48   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 21/40] scsi: megaraid: " Damien Le Moal
2026-09-07  2:56   ` sashiko-bot
2026-09-07 14:50   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 22/40] scsi: myrX: " Damien Le Moal
2026-09-07  2:59   ` sashiko-bot
2026-09-07 14:54   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 23/40] scsi: smartpqi: " Damien Le Moal
2026-09-07  2:57   ` sashiko-bot
2026-09-07 14:57   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 24/40] scsi: qla2xxx: " Damien Le Moal
2026-09-07  2:58   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 25/40] scsi: ps3rom: " Damien Le Moal
2026-09-07  3:03   ` sashiko-bot
2026-09-07 15:25   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 26/40] scsi: lpfc: " Damien Le Moal
2026-09-07  3:02   ` sashiko-bot
2026-09-07 15:26   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 27/40] scsi: stex: " Damien Le Moal
2026-09-07  3:04   ` sashiko-bot
2026-09-07 15:26   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 28/40] scsi: mvumi: " Damien Le Moal
2026-09-07  3:03   ` sashiko-bot
2026-09-07 15:29   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 29/40] scsi: libiscsi: " Damien Le Moal
2026-09-07  3:03   ` sashiko-bot
2026-09-07 15:29   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 30/40] scsi: ibmvscsi_tgt: " Damien Le Moal
2026-09-07  3:05   ` sashiko-bot
2026-09-07 15:32   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 31/40] scsi: scsi_debug: " Damien Le Moal
2026-09-07  3:12   ` sashiko-bot
2026-09-07 15:41   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 32/40] scsi: hpsa: " Damien Le Moal
2026-09-07  3:03   ` sashiko-bot
2026-09-07 15:57   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 33/40] scsi: storvsc: " Damien Le Moal
2026-09-07  3:06   ` sashiko-bot
2026-09-07 15:59   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 34/40] target: " Damien Le Moal
2026-09-07  3:11   ` sashiko-bot
2026-09-07  2:43 ` [PATCH v5 35/40] usb: storage: " Damien Le Moal
2026-09-07  3:02   ` sashiko-bot
2026-09-07 16:13   ` Johannes Thumshirn
2026-09-08  0:27     ` Damien Le Moal
2026-09-08  1:20       ` Alan Stern
2026-09-07  2:43 ` [PATCH v5 36/40] cdrom: " Damien Le Moal
2026-09-07  3:03   ` sashiko-bot
2026-09-07 16:21   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 37/40] ata: libata: " Damien Le Moal
2026-09-07  3:04   ` sashiko-bot
2026-09-07 16:21   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 38/40] s390: scsi: " Damien Le Moal
2026-09-07  3:09   ` sashiko-bot
2026-09-07 16:25   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 39/40] scsi: cleanup scsi_proto.h Damien Le Moal
2026-09-07  3:07   ` sashiko-bot
2026-09-07 16:45   ` Johannes Thumshirn
2026-09-07  2:43 ` [PATCH v5 40/40] scsi: remove scsi_build_sense() and scsi_build_sense_buffer() Damien Le Moal
2026-09-07  3:02   ` sashiko-bot
2026-09-07 16:57   ` Johannes Thumshirn

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=20260907025736.CA7021F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-s390@vger.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