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 org.kernel.vger.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!