On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen wrote:
> On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg
> > wrote:
> > > > On Feb 28, 2025, at 9:14 AM, Paul Moore wrote:
> > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote:
> >
On Tue, Mar 4, 2025 at 9:20 PM Mimi Zohar wrote:
> On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote:
> > On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar wrote:
> > > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> > > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar wrote:
> > > > > On Mon, 2025-
On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar wrote:
> > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar wrote:
> > > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > > > On Fri, Fe
On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar wrote:
> On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar wrote:
> > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar wrote:
> > > > > On Fri, 202
On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar wrote:
> > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar wrote:
> > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > > On Fri,
On Tue, Mar 04, 2025 at 07:25:13PM -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen wrote:
> > On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg
> > > wrote:
> > > > > On Feb 28, 2025, at 9:14 AM, Paul Moore
On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg wrote:
> > On Mar 3, 2025, at 3:40 PM, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg
> > wrote:
> >>> On Feb 28, 2025, at 9:14 AM, Paul Moore wrote:
> >>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote:
> On Thu, 2025-
On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar wrote:
> On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar wrote:
> > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote:
> > > > > On Thu, 20
On Wed, 5 Mar 2025 at 00:52, Bart Van Assche wrote:
>
> On 3/4/25 1:21 AM, Marco Elver wrote:
> > +#include
> > +
> > +/*
> > + * Test that helper macros work as expected.
> > + */
> > +static void __used test_common_helpers(void)
> > +{
> > + BUILD_BUG_ON(capability_unsafe(3) != 3); /* plain
On 3/4/25 1:21 AM, Marco Elver wrote:
+#include
+
+/*
+ * Test that helper macros work as expected.
+ */
+static void __used test_common_helpers(void)
+{
+ BUILD_BUG_ON(capability_unsafe(3) != 3); /* plain expression */
+ BUILD_BUG_ON(capability_unsafe((void)2; 3;) != 3); /* does not
On 3/4/25 1:21 AM, Marco Elver wrote:
Due to the scoped cleanup helpers used for lock guards wrapping
acquire/release around their own constructors/destructors that store
pointers to the passed locks in a separate struct, we currently cannot
accurately annotate *destructors* which lock was releas
On 3/4/25 1:21 AM, Marco Elver wrote:
The conditional definition of lock checking macros and attributes is
about to become more complex. Factor them out into their own header for
better readability, and to make it obvious which features are supported
by which mode (currently only Sparse). This is
On 3/4/25 1:21 AM, Marco Elver wrote:
.../dev-tools/capability-analysis.rst | 2 -
Documentation/mm/process_addrs.rst| 6 +-
.../net/wireless/intel/iwlwifi/iwl-trans.c| 4 +-
.../net/wireless/intel/iwlwifi/iwl-trans.h| 6 +-
.../wireless/intel/iwlwifi/pcie/in
On 3/4/25 1:21 AM, Marco Elver wrote:
Add entry for all new files added for Clang's capability analysis.
Reviewed-by: Bart Van Assche
On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg
> wrote:
> > > On Feb 28, 2025, at 9:14 AM, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote:
> > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > >>>
On Tue, 4 Mar 2025 at 16:29, Peter Zijlstra wrote:
>
> On Tue, Mar 04, 2025 at 10:21:01AM +0100, Marco Elver wrote:
>
> > +# define __asserts_cap(var)
> > __attribute__((assert_capability(var)))
> > +# define __asserts_shared_cap(var)
> > __attribute__((assert_shared_c
On Tue, Mar 04, 2025 at 10:21:01AM +0100, Marco Elver wrote:
> +# define __asserts_cap(var)
> __attribute__((assert_capability(var)))
> +# define __asserts_shared_cap(var)
> __attribute__((assert_shared_capability(var)))
> + static __always_inline void __assert_ca
> On Mar 3, 2025, at 3:40 PM, Paul Moore wrote:
>
> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg
> wrote:
>>> On Feb 28, 2025, at 9:14 AM, Paul Moore wrote:
>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote:
On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>
> I'd sti
On Tue, Mar 04, 2025 at 10:21:07AM +0100, Marco Elver wrote:
> To avoid warnings in constructors, the initialization functions mark a
> capability as acquired when initialized before guarded variables.
Right, took me a bit, but OMG that's a horrific hack :-)
On Tue, 4 Mar 2025 at 13:55, Peter Zijlstra wrote:
>
> On Tue, Mar 04, 2025 at 10:21:05AM +0100, Marco Elver wrote:
> > Due to the scoped cleanup helpers used for lock guards wrapping
> > acquire/release around their own constructors/destructors that store
> > pointers to the passed locks in a sep
On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar wrote:
> > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar wrote:
> > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>
> ...
>
> > O
On Tue, Mar 04, 2025 at 10:21:05AM +0100, Marco Elver wrote:
> Due to the scoped cleanup helpers used for lock guards wrapping
> acquire/release around their own constructors/destructors that store
> pointers to the passed locks in a separate struct, we currently cannot
> accurately annotate *destr
On Tue, 4 Mar 2025 at 12:21, Peter Zijlstra wrote:
>
> On Tue, Mar 04, 2025 at 10:20:59AM +0100, Marco Elver wrote:
>
> > === Initial Uses ===
> >
> > With this initial series, the following synchronization primitives are
> > supported: `raw_spinlock_t`, `spinlock_t`, `rwlock_t`, `mutex`,
> > `seq
On Tue, Mar 04, 2025 at 10:20:59AM +0100, Marco Elver wrote:
> === Initial Uses ===
>
> With this initial series, the following synchronization primitives are
> supported: `raw_spinlock_t`, `spinlock_t`, `rwlock_t`, `mutex`,
> `seqlock_t`, `bit_spinlock`, RCU, SRCU (`srcu_struct`), `rw_semaphore`
While we can opt in individual subsystems which add the required
annotations, such subsystems inevitably include headers from other
subsystems which may not yet have the right annotations, which then
result in false positive warnings.
Making compatible by adding annotations across all common heade
Add support for Clang's capability analysis for mutex.
Signed-off-by: Marco Elver
---
.../dev-tools/capability-analysis.rst | 2 +-
include/linux/mutex.h | 29 +
include/linux/mutex_types.h | 4 +-
lib/test_capability-analysis.c
As discussed in [1], removing __cond_lock() will improve the readability
of trylock code. Now that Sparse context tracking support has been
removed, we can also remove __cond_lock().
Change existing APIs to either drop __cond_lock() completely, or make
use of the __cond_acquires() function attribu
Due to the scoped cleanup helpers used for lock guards wrapping
acquire/release around their own constructors/destructors that store
pointers to the passed locks in a separate struct, we currently cannot
accurately annotate *destructors* which lock was released. While it's
possible to annotate the
With Sparse support gone, Clang is a bit more strict and warns:
./include/linux/console.h:492:50: error: use of undeclared identifier
'console_mutex'
492 | extern void console_list_unlock(void) __releases(console_mutex);
Since it does not make sense to make console_mutex itself global, move
th
Enable capability analysis for stackdepot.
Signed-off-by: Marco Elver
---
v2:
* Remove disable/enable_capability_analysis() around headers.
---
lib/Makefile | 1 +
lib/stackdepot.c | 20 ++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/lib/Makefile b/lib/
Add entry for all new files added for Clang's capability analysis.
Signed-off-by: Marco Elver
Cc: Bart Van Assche
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e0736dc2ee0..cf9bf14f99b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINER
Enable capability analysis for security/tomoyo.
This demonstrates a larger conversion to use Clang's capability
analysis. The benefit is additional static checking of locking rules,
along with better documentation.
Tomoyo makes use of several synchronization primitives, yet its clear
design made
Enable capability analysis for drivers/tty/*.
This demonstrates a larger conversion to use Clang's capability
analysis. The benefit is additional static checking of locking rules,
along with better documentation.
Signed-off-by: Marco Elver
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
v2:
* New pa
Enable capability analysis for rhashtable, which was used as an initial
test as it contains a combination of RCU, mutex, and bit_spinlock usage.
Users of rhashtable now also benefit from annotations on the API, which
will now warn if the RCU read lock is not held where required.
Signed-off-by: Ma
Enable capability analysis for crypto subsystem.
This demonstrates a larger conversion to use Clang's capability
analysis. The benefit is additional static checking of locking rules,
along with better documentation.
Signed-off-by: Marco Elver
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cryp
Enable capability analysis for the KCOV subsystem.
Signed-off-by: Marco Elver
---
v2:
* Remove disable/enable_capability_analysis() around headers.
---
kernel/Makefile | 2 ++
kernel/kcov.c | 36 +---
2 files changed, 27 insertions(+), 11 deletions(-)
diff --g
Enable capability analysis for the KFENCE subsystem.
Notable, kfence_handle_page_fault() required minor restructure, which
also fixed a subtle race; arguably that function is more readable now.
Signed-off-by: Marco Elver
---
v2:
* Remove disable/enable_capability_analysis() around headers.
* Use
Many patterns that involve data-racy accesses often deliberately ignore
normal synchronization rules to avoid taking a lock.
If we have a lock-guarded variable on which we do a lock-less data-racy
access, rather than having to write capability_unsafe(data_race(..)),
simply make the data_race(..) m
Add support for Clang's capability analysis for ww_mutex.
The programming model for ww_mutex is subtly more complex than other
locking primitives when using ww_acquire_ctx. Encoding the respective
pre-conditions for ww_mutex lock/unlock based on ww_acquire_ctx state
using Clang's capability analys
Add support for Clang's capability analysis for local_lock_t.
Signed-off-by: Marco Elver
---
.../dev-tools/capability-analysis.rst | 2 +-
include/linux/local_lock.h| 18
include/linux/local_lock_internal.h | 41 ++---
lib/test_capabili
Remove Sparse support as discussed at [1].
The kernel codebase is still scattered with numerous places that try to
appease Sparse's context tracking ("annotation for sparse", "fake out
sparse", "work around sparse", etc.). Eventually, as more subsystems
enable Clang's capability analysis, these pl
Including into an empty TU will result in the
compiler complaining:
./include/linux/local_lock.h: In function
‘class_local_lock_irqsave_constructor’:
./include/linux/local_lock_internal.h:95:17: error: implicit declaration of
function ‘local_irq_save’; <...>
95 | local_irq_sa
When compiling include/linux/debugfs.h with CAPABILITY_ANALYSIS enabled,
we can see this error:
./include/linux/debugfs.h:239:17: error: use of undeclared identifier
'cancellation'
239 | void __acquires(cancellation)
Move the __acquires(..) attribute after the declaration, so that the
compiler
Mark functions that conditionally acquire the passed lock.
Signed-off-by: Marco Elver
---
include/linux/kref.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 88e82ab1367c..9bc6abe57572 100644
--- a/include/linux/kref.h
+++ b/include/linux/
Add support for Clang's capability analysis for rw_semaphore.
Signed-off-by: Marco Elver
---
.../dev-tools/capability-analysis.rst | 2 +-
include/linux/rwsem.h | 56 +---
lib/test_capability-analysis.c| 64 +++
3 files
Add support for Clang's capability analysis for SRCU.
Signed-off-by: Marco Elver
---
.../dev-tools/capability-analysis.rst | 2 +-
include/linux/srcu.h | 61 +--
lib/test_capability-analysis.c| 24
3 files changed, 66 ins
The annotations for bit_spinlock.h have simply been using "bitlock" as
the token. For Sparse, that was likely sufficient in most cases. But
Clang's capability analysis is more precise, and we need to ensure we
can distinguish different bitlocks.
To do so, add a token capability, and a macro __bitl
Improve the existing annotations to properly support Clang's capability
analysis.
The old annotations distinguished between RCU, RCU_BH, and RCU_SCHED;
however, to more easily be able to express that "hold the RCU read lock"
without caring if the normal, _bh(), or _sched() variant was used we'd
ha
Including into an empty TU will result in the
compiler complaining:
./include/linux/bit_spinlock.h:34:4: error: call to undeclared function
'cpu_relax'; <...>
34 | cpu_relax();
| ^
1 error generated.
Include to allow including bit_spinlo
Add support for Clang's capability analysis for seqlock_t.
Signed-off-by: Marco Elver
---
.../dev-tools/capability-analysis.rst | 2 +-
include/linux/seqlock.h | 24 +++
include/linux/seqlock_types.h | 5 ++-
lib/test_capability-analysis.c
While Sparse is oblivious to the return value of conditional acquire
functions, Clang's capability analysis needs to know the return value
which indicates successful acquisition.
Add the additional argument, and convert existing uses.
Notably, Clang's interpretation of the value merely relates to
Add support for Clang's capability analysis for raw_spinlock_t,
spinlock_t, and rwlock. This wholesale conversion is required because
all three of them are interdependent.
To avoid warnings in constructors, the initialization functions mark a
capability as acquired when initialized before guarded
Clang's capability analysis can be made aware of functions that assert
that capabilities/locks are held.
Presence of these annotations causes the analysis to assume the
capability is held after calls to the annotated function, and avoid
false positives with complex control-flow; for example, where
Warn about applications of capability_unsafe() without a comment, to
encourage documenting the reasoning behind why it was deemed safe.
Signed-off-by: Marco Elver
---
scripts/checkpatch.pl | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
i
Adds documentation in Documentation/dev-tools/capability-analysis.rst,
and adds it to the index and cross-references from Sparse's document.
Signed-off-by: Marco Elver
---
v2:
* Remove cross-reference to Sparse, since we plan to remove Sparse
support anyway.
* Mention __no_capability_analysis s
Add a simple test stub where we will add common supported patterns that
should not generate false positive of each new supported capability.
Signed-off-by: Marco Elver
---
lib/Kconfig.debug | 14 ++
lib/Makefile | 3 +++
lib/test_capability-analysis.c
Capability analysis is a C language extension, which enables statically
checking that user-definable "capabilities" are acquired and released where
required. An obvious application is lock-safety checking for the kernel's
various synchronization primitives (each of which represents a "capability"),
The conditional definition of lock checking macros and attributes is
about to become more complex. Factor them out into their own header for
better readability, and to make it obvious which features are supported
by which mode (currently only Sparse). This is the first step towards
generalizing tow
Capability analysis is a C language extension, which enables statically
checking that user-definable "capabilities" are acquired and released where
required. An obvious application is lock-safety checking for the kernel's
various synchronization primitives (each of which represents a "capability"),
59 matches
Mail list logo
