Re: [PATCH v6 29/56] scsi: qla2xxx: Update handling of ELS IOCBs for 29xx series

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] The `els_entry_24xx_ext` structure uses C bitfields for `vp_index` and `sof_type` over an `__le16` type, which violates kernel hardware interface standards and causes endianness corruption.
- [High] In `qla24xx_process_abts()`, the driver formats the ABTS response for 29xx adapters using the legacy 64-byte `abts_entry_24xx` layout, which truncates the 9-bit `vp_idx` to 8 bits.
- [High] The intermediate `struct qla_els_pt_arg` defines `vp_idx` as a `u8`, which truncates the new 9-bit virtual port indices on 29xx adapters.
--

--- Patch [29]: [PATCH v6 29/56] scsi: qla2xxx: Update handling of ELS IOCBs for 29xx series ---
commit d16d36ca3053582bede2c0cc15922ffd29809f7f
Author: Nilesh Javali <njavali@marvell.com>

scsi: qla2xxx: Update handling of ELS IOCBs for 29xx series

Update ELS IOCB handling to support the extended 128-byte
els_entry_24xx_ext structure used by 29xx series adapters.

> diff --git a/drivers/scsi/qla2xxx/qla_inline.h b/drivers/scsi/qla2xxx/qla_inline.h
> index 49b858e7cf2a1..2ade5e8522516 100644
> --- a/drivers/scsi/qla2xxx/qla_inline.h
> +++ b/drivers/scsi/qla2xxx/qla_inline.h
[ ... ]
> @@ -863,3 +863,31 @@ qla_sts_fwi2_extract(struct qla_hw_data *ha, void *pkt,
> +static inline void
> +qla_els_set_vp_sof(struct scsi_qla_host *vha, void *pkt, u16 vp_idx)
> +{
> +	if (IS_QLA29XX(vha->hw)) {
> +		struct els_entry_24xx_ext *ext = pkt;
> +
> +		ext->vp_index = vp_idx;
> +		ext->sof_type = ELS_EXT_EST_SOFI3;

[Severity: Critical]
Will this cause endianness corruption on big-endian architectures?

Hardware descriptors sent to the device should generally avoid C bitfields
like vp_index and sof_type over an __le16 type, as memory layout is
compiler- and endian-dependent. A native assignment here might generate
host-endian accesses instead of proper little-endian hardware writes, which
could cause the adapter to read garbled virtual port indices and SOF types.

> +	} else {
> +		struct els_entry_24xx *e = pkt;
> +
> +		e->vp_index = vp_idx;
> +		e->sof_type = EST_SOFI3;
> +	}
> +}

> diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
> index 7315bc4df00e4..ab4f5f1ec73fc 100644
> --- a/drivers/scsi/qla2xxx/qla_iocb.c
> +++ b/drivers/scsi/qla2xxx/qla_iocb.c
[ ... ]
> @@ -3322,9 +3323,10 @@ qla24xx_els_dcmd2_iocb(scsi_qla_host_t *vha, int els_opcode,
>  
>  /* it is assume qpair lock is held */
>  void qla_els_pt_iocb(struct scsi_qla_host *vha,
> -	struct els_entry_24xx *els_iocb,
> -	struct qla_els_pt_arg *a)
> +	void *pkt, struct qla_els_pt_arg *a)
>  {
> +	struct els_entry_24xx *els_iocb = pkt;
> +
[ ... ]
> -	els_iocb->vp_index = a->vp_idx;
> -	els_iocb->sof_type = EST_SOFI3;
>  	els_iocb->rx_dsd_count = cpu_to_le16(0);
>  	els_iocb->opcode = a->els_opcode;
>  
> +	qla_els_set_vp_sof(vha, pkt, a->vp_idx);

[Severity: High]
Could this pass a truncated virtual port index for 29xx adapters?

In qla_def.h, struct qla_els_pt_arg defines vp_idx as a u8. Since 29xx
adapters use a 9-bit virtual port index, will assigning a->vp_idx
truncate values >= 256 before they are passed to qla_els_set_vp_sof()?

This might cause ELS passthrough commands to execute on the wrong virtual
port.

> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 75ce09933afc1..404dcb24b6887 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
[ ... ]
> @@ -131,7 +140,7 @@ qla24xx_process_abts(struct scsi_qla_host *vha, struct purex_item *pkt)
>  	}
>  
>  	/* send ABTS response */
> -	abts_rsp = (void *)rsp_els;
> +	abts_rsp = rsp_pkt;
>  	memset(abts_rsp, 0, sizeof(*abts_rsp));
>  	abts_rsp->entry_type = ABTS_RSP_TYPE;
>  	abts_rsp->entry_count = 1;

[Severity: High]
Does this code still format the ABTS response for 29xx adapters using the
legacy 64-byte abts_entry_24xx layout?

If abts_rsp casts rsp_pkt to struct abts_entry_24xx, reading and writing the
8-bit abts->vp_idx later in this function might discard the 9th bit. Would
this cause virtual port indices > 255 to be modulo-256 truncated, routing
ABTS responses to the wrong tenant's virtual port?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723050413.3897522-1-njavali@marvell.com?part=29