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>,
	cassel@kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
	linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
	dlemoal@kernel.org,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 34/40] target: use 16-bits defined sense codes
Date: Fri, 04 Sep 2026 02:37:07 +0000	[thread overview]
Message-ID: <20260904023707.A4E051F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260904002644.157668-35-dlemoal@kernel.org>

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

Pre-existing issues:
- [High] When Unit Attention Interlock Control (`emulate_ua_intlck_ctrl`) is configured to not clear UAs, reporting a Unit Attention fails and results in a permanent `SAM_STAT_BUSY` loop instead of sending a `CHECK_CONDITION`.
--

commit 38089f6eddcf2270af001616b6a77553df3408ee
Author: Damien Le Moal <dlemoal@kernel.org>

target: use 16-bits defined sense codes

Refactor the target core code to use the 16-bits sense codes for building
sense and 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.

No functional change intended.

> diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
> index dcfe945949167..ba208def8cb59 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c

[ ... ]

> @@ -3566,21 +3567,19 @@ static void translate_sense_reason(struct se_cmd *cmd, sense_reason_t reason)
>  
>  	key = sd->key;
>  	if (reason == TCM_CHECK_CONDITION_UNIT_ATTENTION) {
> -		if (!core_scsi3_ua_for_check_condition(cmd, &key, &asc,
> -						       &ascq)) {
> +		if (!core_scsi3_ua_for_check_condition(cmd, &key, &code)) {
>  			cmd->scsi_status = SAM_STAT_BUSY;
>  			return;
>  		}
>  	} else {

[ ... ]

> diff --git a/drivers/target/target_core_ua.c b/drivers/target/target_core_ua.c
> index 4276690fb6cbd..ea97b05d47ab7 100644
> --- a/drivers/target/target_core_ua.c
> +++ b/drivers/target/target_core_ua.c

[ ... ]

> @@ -232,8 +230,7 @@ bool core_scsi3_ua_for_check_condition(struct se_cmd *cmd, u8 *key, u8 *asc,
>  		 * clearing it.
>  		 */
>  		if (!dev_ua_intlck_clear) {
> -			*asc = ua->ua_asc;
> -			*ascq = ua->ua_ascq;
> +			*code = scsi_sense_code(ua->ua_asc, ua->ua_ascq);
>  			break;
>  		}

[Severity: High]
This is a pre-existing issue, but I noticed a logic error in the UA reporting
mechanism that is still present.

When core_scsi3_ua_for_check_condition() executes the `!dev_ua_intlck_clear`
branch shown above, it breaks out of the loop early without setting the local
variable `head = 0`. Because the function simply returns `head == 0` at the end,
it will always return false in this case.

As a result, when called by translate_sense_reason(), this false return value
causes the target to respond with SAM_STAT_BUSY instead of building the proper
CHECK_CONDITION sense buffer.

Could this lead to an infinite retry loop? If the target responds with BUSY,
the initiator might indefinitely retry the command since the Unit Attention is
never cleared or properly reported, potentially making the LUN completely
inaccessible.

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

  reply	other threads:[~2026-09-04  2:37 UTC|newest]

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

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=20260904023707.A4E051F000E9@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