Re: [PATCH v6 03/56] scsi: qla2xxx: Add NVRAM config support for 29xx adapters

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The pointer ha->fiv is not set to NULL when qla29xx_read_optrom_data() fails, leaving it pointing to a zeroed buffer instead of correctly indicating absence.
--

--- Patch [3]: [PATCH v6 03/56] scsi: qla2xxx: Add NVRAM config support for 29xx adapters ---
commit d8579bb80f870f714d329c213d6291f565f67160
Author: Manish Rangankar <mrangankar@marvell.com>

scsi: qla2xxx: Add NVRAM config support for 29xx adapters

Extend the NVRAM read and configuration-apply paths to handle the
29xx series.  The 29xx NVRAM layout is similar to the 81xx family,
so reuse the existing nvram_81xx parsing while adding
29xx-specific fields and init-sequence integration.

Closes: https://lore.kernel.org/oe-kbuild-all/202607141733.w1IF5m43-lkp@intel.com/

> diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
> index e23e7ac48ae26..c6e928f11758c 100644
> --- a/drivers/scsi/qla2xxx/qla_init.c
> +++ b/drivers/scsi/qla2xxx/qla_init.c
[ ... ]
> @@ -9306,35 +9306,98 @@ qla81xx_nvram_config(scsi_qla_host_t *vha)
[ ... ]
>  	if (IS_QLA29XX(ha)) {
>  		uint16_t fw_options = 0, r_code;
>  		uint32_t vpd_r[] = {FLT_REG_VPD_0, FLT_REG_VPD_1,
>  				    FLT_REG_VPD_2, FLT_REG_VPD_3};
>  		uint32_t nvram_r[] = {FLT_REG_NVRAM_0, FLT_REG_NVRAM_1,
>  				      FLT_REG_NVRAM_2, FLT_REG_NVRAM_3};
>  		void *buf;
>  
>  		BUILD_BUG_ON((VPD_OFFSET + FA_NVRAM_VPD_SIZE +
>  			      sizeof(struct qla_flash_memo_block)) >
>  			     MAX_NVRAM_SIZE);
>  
>  		ha->fiv = (struct qla_flash_memo_block *)
>  			((char *)ha->vpd + ha->vpd_size);
>  
>  		buf = qla29xx_read_optrom_data(vha, FLT_REG_FMB_PRI,
>  					       fw_options, ha->fiv, 0,
>  					       sizeof(struct qla_flash_memo_block));
>  		if (!buf) {
>  			ql_log(ql_log_info, vha, 0x01be,
>  			    "Unable to read Flash Image Version.\n");

[Severity: Low]
Should ha->fiv be set to NULL here when the FMB read fails?

Currently, if qla29xx_read_optrom_data() returns NULL, ha->fiv continues to
point at (ha->vpd + ha->vpd_size) rather than correctly indicating absence. In
the signature mismatch case below, it is explicitly set to NULL. Does this
leave a dangling reference to uninitialized memory that could confuse future
code checking if ha->fiv is valid?

>  		} else if (ha->fiv->signature != QLFC_FMB_SIG) {
>  			ql_log(ql_log_warn, vha, 0x01bf,
>  			    "Invalid FMB signature %#x, expected %#x.\n",
>  			    le32_to_cpu(ha->fiv->signature),
>  			    le32_to_cpu(QLFC_FMB_SIG));
>  			ha->fiv = NULL;
>  		} else {
[ ... ]

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