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
