Re: [PATCHv2 07/17] nvme: add Clang context annotations for nvme_subsystem::lock

[Nilay Shroff <nilay@linux.ibm.com>]

On 7/9/26 12:54 PM, Marco Elver wrote:
> On Thu, 9 Jul 2026 at 08:20, Christoph Hellwig <hch@lst.de> wrote:
>>
>> On Tue, Jun 30, 2026 at 01:12:55AM +0200, Marco Elver wrote:
>>> Initialization of guarded objects has gone through a few iterations,
>>
>> And all of them suck badly, with the current one being the worse.
>>
>>> so I don't want to open that can of worms again. I think the
>>> infrastructure we have now provides various options (the scoped guard
>>> machinery isn't the only way). You could just write:
>>>
>>> /* Initializes unpublished lock-guarded variables. */
>>> context_unsafe(
>>>      INIT_LIST_HEAD(&subsys->nsheads);
>>>      // ... other guarded var init in same block ...
>>> );
>>
>> Using all these silly context makes it total mess unfortunately.
> 
> The only option then is to just mark the whole function
> __context_unsafe(init). We can't have it both ways: analyze an init
> function but ignore lock-guarded accesses without annotations.
> 
> I'm out of ideas, because this is fundamentally unsolvable problem
> with what the C language gives us. The C language has no explicit
> constructors, and therefore our semantic intent cannot magically be
> communicated to the compiler without additional syntax; we need some
> way to mark things in C. My initial attempt of making it closer to
> magic:
> 
>      mutex_init(&x->mu);
>      x->var = 123;  // var is __guarded_by(&mu)
> 
> was rejected [1] on the grounds that we might want analysis in an init
> function after the context-lock-init. And that's reasonable if we
> favor safety over the minor inconvenience of marking initialization.
> __context_unsafe(init) is the option to not need to change the code
> but gets us no analysis in an init function whatsoever.
> 
> [1] https://lore.kernel.org/all/20260115005231.1211866-1-elver@google.com/
> 
> Aside, in the C++ world where constructors exist, Clang just disables
> the analysis completely in ctors to permit lock-guarded variable
> initialization. So __context_unsafe(init) attribute on a function is
> equivalent, given C has no ctors.

Okay it seems in that case there's no other choice left for C language, and
so I'd annotate init function using __context_unsafe.

Thanks,
--Nilay