Re: [PATCH v5 02/13] scsi: fnic: Use fnic_num for non-SCSI identifiers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unconditional use of fnic_num in fnic_fcpio_ack_handler trace events breaks event correlation for FCP initiators.
--

commit 899ac498b451c2fff04272de1bf2b696b5332d70
Author: Karan Tilak Kumar <kartilak@cisco.com>

scsi: fnic: Use fnic_num for non-SCSI identifiers

This commit updates the driver to use the fnic instance number for
NVMe-facing FDMI and debugfs entries, and for trace events. It aims to
reserve SCSI host numbers strictly for FCP initiator paths.

[ ... ]

> diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
> index 0759540f66753..b92260583c67b 100644
> --- a/drivers/scsi/fnic/fnic_scsi.c
> +++ b/drivers/scsi/fnic/fnic_scsi.c
> @@ -894,7 +894,7 @@ static inline void fnic_fcpio_ack_handler(struct fnic *fnic,
>  
>  	spin_unlock_irqrestore(&fnic->wq_copy_lock[wq_index], flags);
>  	FNIC_TRACE(fnic_fcpio_ack_handler,
> -		  fnic->host->host_no, 0, 0, ox_id_tag[2], ox_id_tag[3],
> +		  fnic->fnic_num, 0, 0, ox_id_tag[2], ox_id_tag[3],

[Severity: Medium]
Will this unconditional use of fnic_num break trace event correlation for
FCP initiators?

Other FCP-specific trace events continue to use the SCSI midlayer-allocated
host_no. By changing fnic_fcpio_ack_handler() to use fnic_num
unconditionally, a single FCP I/O sequence will interleave two different
identifier values in the trace buffer (e.g., host_no 2 vs fnic_num 0) on
systems with other SCSI controllers.

Should this trace call check IS_FNIC_FCP_INITIATOR(fnic) to log the host_no
for FCP traffic, similar to the debugfs and FDMI changes?

>  		  ox_id_tag[4], ox_id_tag[5]);
>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624044334.3079-1-kartilak@cisco.com?part=2