Re: [PATCH v4 3/6] scsi: core: Pass the SCSI host pointer directly
John Garry <[email protected]> Mon, 3 Aug 2026 17:30:27 +0100
| Newsgroups | gmane.linux.scsi |
|---|---|
| Organization | Oracle Corporation |
| Message-ID | <[email protected]> |
On 03/08/2026 17:14, Bart Van Assche wrote: > On 8/3/26 6:=E2=80=8A01 AM, John Garry wrote: > On 31/07/2026 22:=E2=80= =8A52, Bart Van Assche > wrote: > > "Pass the SCSI host pointer directly" - that's too vague a tit= le. > Huh? This patch passes the SCSI host pointer directly to several function= s instead >=20 >=20 > On 8/3/26 6:01 AM, John Garry wrote: >> On 31/07/2026 22:52, Bart Van Assche wrote: >>=20 >> "Pass the SCSI host pointer directly" - that's too vague a title. >=20 > Huh? This patch passes the SCSI host pointer directly to several > functions instead of deriving the SCSI host pointer from the SCSI target > pointer (dev_to_shost(starget->dev.parent)). Hence, I think the title is > accurate. >=20 I wrote vague, as in "Pass the SCSI host pointer directly" to and from=20 what? I would have "Pass the SCSI host pointer to scan-related=20 functions" or similar. >>> In the functions scsi_probe_and_add_lun(), scsi_sequential_lun_scan(), >>> scsi_report_lun_scan() and __scsi_scan_target() the SCSI host pointer is >>> derived from the SCSI target pointer. Pass the SCSI host pointer >>> directly. This patch prepares for enabling lock context analysis. >>=20 >> How? >=20 > With this patch, lock context annotations can refer to the SCSI host > pointer directly (__must_hold(&shost->scan_mutex)). Without this patch, > the following lock context annotation would have to be used instead: >=20 > __must_hold(&dev_to_shost(starget->dev.parent)->scan_mutex) >=20 > Additionally, in code that locks shost->scan_mutex, the following would > have to be added to help the compiler understand that shost =3D=3D > dev_to_shost(starget->dev.parent): >=20 > __assume_ctx_lock(&dev_to_shost(starget->dev.parent)->scan_mutex); >=20 > Christoph Hellwig made it clear during the LSF/MM/BPF summit that he is > doesn't like __assume_ctx_lock() statements being added and also that he > prefers to add arguments to functions if that eliminates the need for > introducing __assume_ctx_lock() statements. Hence this patch. >=20 ok, I get it, but it's better to mention the reason briefly, like=20 "context analysis requires checking on passed argument when using=20 preferred annotation form" Thanks!