Re: [PATCH 01/11] blk-mq: Add blk_mq_init_queue_ops()

[Hannes Reinecke]

On 3/22/22 16:17, John Garry wrote:
> On 22/03/2022 14:03, Hannes Reinecke wrote:
> > > As mentioned in the cover letter response, it just seems best to keep 
> > > the normal scsi_cmnd payload but have other means to add on the 
> > > internal command data, like using host_scribble or scsi_cmnd priv data.
> > Well; I found that most drivers I had been looking at the scsi command 
> > payload isn't used at all; the drivers primarily cared about the 
> > (driver-provided) payload, and were completely ignoring the scsi 
> > command payload.
> >
> > Similar for ATA/libsas: you basically never issue real scsi commands, 
> > but either 'raw' ATA requests or SCSI TMFs. None of which are scsi 
> > commands, so providing them is a bit of a waste.
> >
> > (And causes irritations, too, as a scsi command requires associated 
> > pointers like ->device etc to be set up. Which makes it tricky to use 
> > for the initial device setup.)
>
> A problem I see is that in scsi_mq_init_request() we allocate memories 
> like sense_buffer and prot_sdb and store the pointers in the scsi_cmnd 
> payload. If we then reuse a scsi_cmnd payload as an "internal" command 
> payload then this data may be lost.
>
> It might be possible to reuse the scsi cmnd payload for the "internal", 
> but I would rather not get hung up on it now if possible.
Or, keep the payload as is, and use the 'internal' marker to indicate 
that the scsi payload is not valid.
That would save us quite some checks during endio processing.

Cheers,

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