Re: [PATCH v3 41/88] scsi: qla2xxx: Replace __le16 bitfields with scalar and accessors

[sashiko-bot@kernel.org]

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

New issues:
- [High] The patch fixes endianness issues for `__le16` bitfields in 29xx extended IOCBs, but misses the identical bitfield layout bug in `struct vp_rpt_id_entry_24xx_ext`.

Pre-existing issues:
- [High] Target mode structures rely on `uint8_t` bitfields that are broken on big-endian architectures.
--

--- Patch [41]: [PATCH v3 41/88] scsi: qla2xxx: Replace __le16 bitfields with scalar and accessors ---
commit 2a52cf1de747d5bdd6a7b2e026697c3d01b78f41
Author: Nilesh Javali <njavali@marvell.com>

scsi: qla2xxx: Replace __le16 bitfields with scalar and accessors

This commit fixes endianness issues for __le16 bitfields in the 29xx extended
IOCB structures by replacing them with a single __le16 scalar field and
accessor functions. It applies this fix to els_entry_24xx_ext,
els_sts_entry_24xx_ext, and abts_entry_24xx_ext to prevent incorrect bit
positions on big-endian hosts.

> diff --git a/drivers/scsi/qla2xxx/qla_fw29.h b/drivers/scsi/qla2xxx/qla_fw29.h
> index 600a40d8bd5ff..63bf350ddffc0 100644
> --- a/drivers/scsi/qla2xxx/qla_fw29.h
> +++ b/drivers/scsi/qla2xxx/qla_fw29.h
[ ... ]
> @@ -563,9 +586,7 @@ struct abts_entry_24xx_ext {
>  	__le16	nport_handle;		/* type 0x54 only */
>  
>  	__le16	control_flags;		/* type 0x55 only */
> -	__le16	vp_idx : 9;		/* VP index 9 bits */
> -	__le16	reserved_1_sof : 3;
> -	__le16	sof_type : 4;		/* sof_type is upper nibble */
> +	__le16	vp_idx_sof;		/* bits [8:0]=VP index, [15:12]=SOF type */
>  
>  	__le32	rx_xch_addr;
>  

[Severity: High]
Are there other structures in this file that require a similar update?

It appears struct vp_rpt_id_entry_24xx_ext uses a similar __le16 bitfield 
layout that could result in hardware payload parsing corruption on 
big-endian systems:

struct vp_rpt_id_entry_24xx_ext {
	...
	__le16 vp_idx : 9;
	__le16 vp_status : 7;
	...
}

If left unpatched, could qla24xx_report_id_acquisition() read incorrect 
VP IDs and statuses during firmware responses on big-endian platforms?

[Severity: High]
This is a pre-existing issue, but does the target mode code suffer from a 
similar problem? 

Looking at struct abts_recv_from_24xx and struct atio7_fcp_cmnd in 
drivers/scsi/qla2xxx/qla_target.h, they use uint8_t bitfields directly mapped 
to hardware structures without endianness protections:

struct abts_recv_from_24xx {
	...
	uint8_t reserved_3:4;
	uint8_t sof_type:4;
	...
}

struct atio7_fcp_cmnd {
	...
	uint8_t task_attr:3;
	uint8_t reserved:5;
	...
}

Could these declarations cause hardware payload corruption on big-endian 
hosts for target-mode FC communication, given they lack the usual endianness 
guards?

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