[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250221185220.GA7373@noisy.programming.kicks-ass.net>
Date: Fri, 21 Feb 2025 19:52:20 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Marco Elver <elver@...gle.com>, Alexander Potapenko <glider@...gle.com>,
Bart Van Assche <bvanassche@....org>,
Bill Wendling <morbo@...gle.com>, Boqun Feng <boqun.feng@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Frederic Weisbecker <frederic@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>, Jann Horn <jannh@...gle.com>,
Joel Fernandes <joel@...lfernandes.org>,
Jonathan Corbet <corbet@....net>,
Josh Triplett <josh@...htriplett.org>,
Justin Stitt <justinstitt@...gle.com>, Kees Cook <kees@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Miguel Ojeda <ojeda@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Uladzislau Rezki <urezki@...il.com>,
Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>,
kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, rcu@...r.kernel.org,
linux-crypto@...r.kernel.org
Subject: Re: [PATCH RFC 15/24] rcu: Support Clang's capability analysis
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.
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.
Powered by blists - more mailing lists