[PATCH 5/8] scsi: scsi-multipath: Add basic ALUA support
John Garry
john.g.garry at oracle.com
Mon Mar 16 02:25:06 PDT 2026
On 14/03/2026 04:48, Benjamin Marzinski wrote:
>> + ext_hdr_unsupp = true;
>> + goto retry;
>> + }
>> + /*
>> + * If the array returns with 'ALUA state transition'
>> + * sense code here it cannot return RTPG data during
>> + * transition. So set the state to 'transitioning' directly.
>> + */
>> + if (sense_hdr.sense_key == NOT_READY &&
>> + sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a)
>> + goto out;
> This check is odd. First, we don't set the state to 'transitioning' like
> the comment says. We don't set alua_state at all, which ends up meaning
> that it stays as 0 (SCSI_ACCESS_STATE_OPTIMAL). It seems like we should
> explicitly set it and make the comment reflect that, if just to aid
> understanding of the logic.
Yeah, I have to admit that this is all bodged the a bit, as
transitioning is not properly handled. Instead of "basic" ALUA support,
this really is limited ALUA support.
I am now looking at a way to have a core scsi ALUA driver to handle all
of this, but it is challenging as we need to continue ALUA DH support.
>
> Nitpick: Also, this is the only place where we goto out. All the other
> checks individually free the buffer and return directly. I realize that
> all the other checks that exit early are errors, but it seems like we
> could just return a variable at the end of the function.
Sure, I can pay attention to this. However, as mentioned above, I am
experimenting with moving any ALUA specifics into scsi core code.
>
>> +
>> + /*
>> + * Retry on any other UNIT ATTENTION occurred.
>> + */
>> + if (sense_hdr.sense_key == UNIT_ATTENTION) {
>> + scsi_print_sense_hdr(sdev, __func__, &sense_hdr);
>> + kfree(buff);
>> + return -EAGAIN;
>> + }
> If we get a UNIT ATTENTION, we end up failing scsi_mpath_dev_alloc(),
> not retrying. Aside from the comment being wrong, it seems very brittle
> to fail here, just because we got a UNIT ATTENTION.
Ack
Thanks,
John
More information about the Linux-nvme
mailing list