Re: [PATCH v2 00/34] Compiler-Based Capability- and Locking-Analysis

[Peter Zijlstra <peterz@infradead.org>]

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`,
> `local_lock_t`, `ww_mutex`.

Wasn't there a limitation wrt recursion -- specifically RCU is very much
a recursive lock and TS didn't really fancy that?


>   - Rename __var_guarded_by to simply __guarded_by. Initially the idea
>     was to be explicit about if the variable itself or the pointed-to
>     data is guarded, but in the long-term, making this shorter might be
>     better.
> 
>   - Likewise rename __ref_guarded_by to __pt_guarded_by.

Shorter is better :-)

Anyway; I think I would like to start talking about extensions for these
asap.

Notably I feel like we should have a means to annotate the rules for
access/read vs modify/write to a variable.

The obvious case is RCU; where holding RCU is sufficient to read, but
modification requires a 'real' lock. This is not something that can be
currently expressed.

The other is the lock pattern I touched upon the other day, where
reading is permitted when holding one of two locks, while writing
requires holding both locks.

Being able to explicitly write that in the __guarded_by() annotations is
the cleanest way I think.

Anyway, let me go stare at the actual patches :-)