Re: [PATCH v4 38/56] scsi: qla2xxx: Add LS4 pass-through IOCB handling for 29xx series

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Silent truncation of the 9-bit vp_index to 8 bits when handling NVMe LS rejects and aborts on 29xx adapters.
- [High] Incoming unsolicited NVMe LS requests silently truncate the 9-bit vp_index on 29xx adapters due to missing extended structure.
--

--- Patch [38]: [PATCH v4 38/56] scsi: qla2xxx: Add LS4 pass-through IOCB handling for 29xx series ---
commit d14caf7c2396c7b59c2084f1b4f6a4306e45737c
Author: Manish Rangankar <mrangankar@marvell.com>

scsi: qla2xxx: Add LS4 pass-through IOCB handling for 29xx series

This commit extends the LS4 pass-through IOCB handling to support the
128-byte pt_ls4_request_ext layout used by 29xx series adapters. The
extension grows inline DSD capacity from 2 to 5 entries and handles the
divergent fields per adapter stride.

> diff --git a/drivers/scsi/qla2xxx/qla_nvme.c b/drivers/scsi/qla2xxx/qla_nvme.c
> index 8fa980db6ce4e..0038b6274d444 100644
> --- a/drivers/scsi/qla2xxx/qla_nvme.c
> +++ b/drivers/scsi/qla2xxx/qla_nvme.c

[ ... ]

> @@ -1197,37 +1197,57 @@ static void qla_nvme_fc_format_rjt(void *buf, u8 ls_cmd, u8 reason,
>  	rjt->rjt.vendor = vendor;
>  }
>  

[ ... ]

> +	if (IS_QLA29XX(ha)) {
> +		struct pt_ls4_request_ext *ext = lsrjt_iocb;
> +
> +		ext->vp_index = cpu_to_le16(a->vp_idx);

[Severity: High]
Can this silently truncate the 16-bit virtual port index?

Looking at struct qla_nvme_lsrjt_pt_arg, vp_idx is defined as an 8-bit
value:

struct qla_nvme_lsrjt_pt_arg {
	...
	u8 vp_idx;
	...

When an unsolicited NVMe LS request fails or needs to be rejected, this
u8 field silently truncates the 16-bit vha->vp_idx upon assignment. We
then assign this 8-bit truncated value to the extended IOCB's 16-bit
ext->vp_index here.

Could this cause NVMe LS reject requests to be routed out of the wrong
virtual port if the vport index is >= 256, breaking functionality for
NPIV ports on 29xx adapters?

> +		ext->tx_byte_count = cpu_to_le32(a->tx_byte_count);
> +		ext->rx_byte_count = 0;
> +		put_unaligned_le64(a->tx_addr, &ext->dsd[0].address);
> +		ext->dsd[0].length = cpu_to_le32(a->tx_byte_count);
> +		put_unaligned_le64(a->rx_addr, &ext->dsd[1].address);
> +		ext->dsd[1].length = 0;
> +	} else {

[ ... ]

> diff --git a/drivers/scsi/qla2xxx/qla_nvme.h b/drivers/scsi/qla2xxx/qla_nvme.h
> index a253ac55171bd..e6a41d53cbe1c 100644
> --- a/drivers/scsi/qla2xxx/qla_nvme.h
> +++ b/drivers/scsi/qla2xxx/qla_nvme.h
> @@ -144,7 +144,7 @@ struct pt_ls4_rx_unsol {

[Severity: High]
Does incoming unsolicited NVMe LS request handling truncate the 9-bit
vp_index on 29xx adapters?

When a 29xx adapter delivers an unsolicited LS request, it posts an
extended RX IOCB. If the driver casts it to the unextended 64-byte
struct pt_ls4_rx_unsol, vp_index is read as a uint8_t, truncating the
9-bit index provided by the hardware to 8 bits.

Should there be an extended layout for struct pt_ls4_rx_unsol for 29xx
adapters to ensure unsolicited NVMe LS requests on VPs >= 256 are not
misrouted?

>  int qla_nvme_register_hba(struct scsi_qla_host *);
>  int  qla_nvme_register_remote(struct scsi_qla_host *, struct fc_port *);
>  void qla_nvme_delete(struct scsi_qla_host *);
> -void qla24xx_nvme_ls4_iocb(struct scsi_qla_host *, struct pt_ls4_request *,
> -    struct req_que *);
> +void qla24xx_nvme_ls4_iocb(struct scsi_qla_host *vha, void *pkt,
> +			   struct req_que *req);
>  void qla24xx_async_gffid_sp_done(struct srb *sp, int);
>  #endif

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