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

Nilay Shroff <[email protected]>
Newsgroups org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/9/26 12:54 PM, Marco Elver wrote:
> On Thu, 9 Jul 2026 at 08:20, Christoph Hellwig <[email protected]> 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/[email protected]/
> 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.