Re: [PATCH v7 5/6] scsi: core: Protect host state changes with the host lock

On Fri, 14 Aug 2026 at 17:41, Bart Van Assche <[email protected]> wrote:
>
> On 8/14/26 7:59 AM, John Garry wrote:
> > with my changes in https://lore.kernel.org/linux-scsi/
> > [email protected]/T/
> > #m064c12513575565cc08afa15738215b98bcca142 on top of this series, I
> > notice that the following 2x forms of annotation are compliant for the
> > context analysis checking:
> >
> > __must_hold(shost->host_lock)
> > __must_hold(&shost->host_lock)
>
> This is consistent with my observations - it seems like Clang accepts
> both forms. Marco, do you perhaps know whether this is a bug or a
> feature? I couldn't find the answer to this question in
> https://clang.llvm.org/docs/ThreadSafetyAnalysis.html.

Both forms are accepted by design: annotations model abstract
capability identity rather than runtime memory access, so Clang
uniquely identifies the underlying lock either way (internally, & and
* are treated as no-ops when building capability expressions).

Since [1], the one case where in C the & was required was also fixed
and both forms work for pointer-to-member annotations.

[1] https://github.com/llvm/llvm-project/pull/194457

But I've stuck to using pointers in annotations: kernel locking APIs
always operate on pointers (e.g. spin_lock(&lock)), and sticking to
the pointer-to-lock form in annotations is consistent with that. But
nothing enforces that, so it's more of a style and readability
question.