Re: [PATCH v2 24/44] libfc: Stop using the SCSI pointer

[Hannes Reinecke <hare@suse.de>]

On 2/8/22 18:24, Bart Van Assche wrote:
> Move the fc_fcp_pkt pointer, the residual length and the SCSI status into
> the new data structure libfc_cmd_priv. This patch prepares for removal of
> the SCSI pointer from struct scsi_cmnd.
> 
> The libfc users have been identified as follows:
> 
> $ git grep -lw 'libfc_host_alloc' | grep -v /libfc
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> drivers/scsi/fcoe/fcoe.c
> drivers/scsi/fnic/fnic_main.c
> drivers/scsi/qedf/qedf_main.c
> 
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Saurav Kashyap <skashyap@marvell.com>
> Cc: Javed Hasan <jhasan@marvell.com>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>   drivers/scsi/bnx2fc/bnx2fc.h      | 10 ++++++++--
>   drivers/scsi/bnx2fc/bnx2fc_fcoe.c |  1 +
>   drivers/scsi/bnx2fc/bnx2fc_io.c   | 20 ++++++++++----------
>   drivers/scsi/fcoe/fcoe.c          |  1 +
>   drivers/scsi/fnic/fnic.h          |  1 +
>   drivers/scsi/libfc/fc_fcp.c       | 26 +++++++++++---------------
>   drivers/scsi/qedf/qedf.h          | 11 ++++++++++-
>   drivers/scsi/qedf/qedf_io.c       | 16 ++++++++--------
>   drivers/scsi/qedf/qedf_main.c     |  3 ++-
>   include/scsi/libfc.h              | 11 +++++++++++
>   10 files changed, 63 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
> index b4cea8b06ea1..08deed26c51e 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc.h
> +++ b/drivers/scsi/bnx2fc/bnx2fc.h
> @@ -137,8 +137,6 @@
>   #define BNX2FC_FW_TIMEOUT		(3 * HZ)
>   #define PORT_MAX			2
>   
> -#define CMD_SCSI_STATUS(Cmnd)		((Cmnd)->SCp.Status)
> -
>   /* FC FCP Status */
>   #define	FC_GOOD				0
>   
> @@ -493,7 +491,15 @@ struct bnx2fc_unsol_els {
>   	struct work_struct unsol_els_work;
>   };
>   
> +struct bnx2fc_priv {
> +	struct libfc_cmd_priv libfc_data; /* must be the first member */
> +	struct bnx2fc_cmd *io_req;
> +};
>   
I am not sure this is correct.

Both, libfc and the fcoe drivers do use SCp.ptr, but from what I can see 
each in different ways.
So I'm not sure that we need to stack the private data; we never did 
that previously.
Some more careful audit is required to separate out the usage here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer