Re: [PATCH v2 05/20] scsi: core: Add support for internal commands

[Bart Van Assche <bvanassche@acm.org>]

On 11/23/21 12:13 AM, Hannes Reinecke wrote:
> It's actually a bit more involved.
> 
> The biggest issue is that the SCSI layer is littered with the assumption
> that there _will_ be a ->device pointer in struct scsi_cmnd.
> If we make up a scsi_cmnd structure _without_ that we'll have to audit
> the entire stack to ensure we're not tripping over a NULL device pointer.
> And to make matters worse, we also need to audit the completion path in
> the driver, which typically have the same 'issue'.
> 
> Case in point:
> 
> # git grep -- '->device' drivers/scsi | wc --lines
> 2712
> 
> Which was the primary reason for adding a stub device to the SCSI Host;
> simply to avoid all the pointless churn and have a valid device for all
> commands.
> 
> The only way I can see how to avoid getting dragged down into that
> rat-hole is to _not_ returning a scsi_cmnd, but rather something else
> entirely; that's the avenue I've exploited with my last patchset which
> would just return a tag number.
> But as there are drivers which really need a scsi_cmnd I can't se how we
> can get away with not having a stub scsi_device for the scsi host.
> 
> And that won't even show up in sysfs if we assign it a LUN number beyond
> the addressable range; 'max_id':0 tends to be a safe choice here.

There is no risk that the scsi_cmnd.device member will be dereferenced for
internal requests allocated by the UFS driver. But I understand from your
email that making sure that the scsi_cmnd.device member is not NULL is
important for other SCSI LLDs. I will look into the approach of associating
a stub SCSI device with internal requests.

Thanks,

Bart.