On Fri, 21 Feb 2025 at 19:52, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Fri, Feb 21, 2025 at 10:08:06AM -0800, Paul E. McKenney wrote: > > > > ... unfortunately even for shared locks, the compiler does not like > > > re-entrancy yet. It's not yet supported, and to fix that I'd have to go > > > and implement that in Clang first before coming back to this. > > > > This would be needed for some types of reader-writer locks, and also for > > reference counting, so here is hoping that such support is forthcoming > > sooner rather than later. > > Right, so I read the clang documentation for this feature the other day, > and my take away was that this was all really primitive and lots of work > will need to go into making this more capable before we can cover much > of the more interesting things we do in the kernel. > > Notably the whole guarded_by member annotations, which are very cool in > concept, are very primitive in practise and will need much extensions. I have one extension in flight: https://github.com/llvm/llvm-project/pull/127396 - it'll improve coverage for pointer passing of guarded_by members. Anything else you see as urgent? Re-entrant locks support a deal breaker? But yes, a lot of complex locking patterns will not easily be expressible right away. > To that effect, and because this is basically a static analysis pass > with no codegen implications, I would suggest that we keep the whole > feature limited to the very latest clang version for now and don't > bother supporting older versions at all. Along those lines, in an upcoming v2, I'm planning to bump it up to Clang 20+ because that version introduced a reasonable way to ignore warnings in not-yet-annotated headers: https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git/commit/?h=cap-analysis/dev&id=2432a39eae8197f5058c578430bd1906c18480c3
