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.
