[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90c7a807-b0a0-4b42-866f-f74c5d1c62e5@acm.org>
Date: Thu, 6 Feb 2025 10:34:09 -0800
From: Bart Van Assche <bvanassche@....org>
To: Marco Elver <elver@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>,
Christoph Hellwig <hch@....de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nathan Chancellor <nathan@...nel.org>, Kees Cook <kees@...nel.org>,
Jann Horn <jannh@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 00/33] Compile-time thread-safety checking
On 2/6/25 10:20 AM, Marco Elver wrote:
> Combining approach #1 and #2 may somehow be possible, but it is
> currently eluding me. Clearly, based on the bugs that Bart found, some
> way to do tree-wide analysis is very useful!
> One idea was to have "capability-selective tree-wide analysis" (such
> as mutex only) be controllable via a Kconfig option - the
> implementation of that (without excessive ifdefs sprinkled
> everywhere), however, most likely requires compiler support.
>
> Depending on the feedback that results from these RFCs, I think we
> will be able to plan better which direction things should go.
Thank you Marco for having explained clearly and in detail what the
possible paths are for enabling thread-safety support in the Linux
kernel. I agree that there are at least two possible approaches (maybe
there are even more possible approaches?). I'm interested in enabling
the Clang compiler flag -Wthread-safety across the entire kernel. Hence
the choice to start with annotating struct mutex only and to make the
necessary changes across the entire kernel tree.
I'm looking forward to the feedback from others about what their opinion
is about how to enable thread-safety checking in the Linux kernel.
Thanks,
Bart.
Powered by blists - more mailing lists