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