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

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.