Re: [PATCH v2] locking/percpu-rwsem: Annotate intentional data race in readers_active_check()

[Peter Zijlstra]

On Tue, Jun 23, 2026 at 06:41:32PM +0800, Sun Shaojie wrote:
> KCSAN reports a data race between readers_active_check() and a
> concurrently executing reader:
> 
>   BUG: KCSAN: data-race in readers_active_check / percpu_down_write
> 
>   race at unknown origin, with read to 0xffff9f3eb5bf5f30 of 4 bytes
>   by task 1271 on cpu 14:
>    readers_active_check+0x...
>    percpu_down_write+0x152/0x1f0
> 
>   value changed: 0xfffffff9 -> 0xfffffff8
> 
> readers_active_check() calls per_cpu_sum(*sem->read_count), which
> iterates over all CPUs and reads each CPU's per-CPU read_count
> variable.  Concurrently, a reader on a remote CPU is modifying its own
> CPU's read_count via this_cpu_inc() / this_cpu_dec() as it enters and
> exits the critical section.  These are plain reads and writes to the
> same per-CPU storage, hence KCSAN flags a data race.
> 
> This race is benign.  readers_active_check() is called from the
> percpu_down_write() wait loop (rcuwait_wait_event) after sem->block is
> already set.  At this point:
> 
>   - New readers must immediately back out (they see block set, decrement
>     their counter, and wake the writer), so counters can only decrease.
> 
>   - If the sum catches a reader's increment before its decrement,
>     readers_active_check() sees a non-zero sum and returns false.  The
>     writer merely iterates the wait loop again -- a harmless retry.
> 
>   - A false zero (observing sum == 0 while a reader is still active)
>     cannot happen: per_cpu_sum() reads each CPU's counter, and each
>     per-CPU int read is atomic on all architectures, so an active
>     reader's counter is always seen as non-zero.
> 
> Annotate the read with data_race() to suppress the KCSAN warning and
> document the intentional nature of this unlocked access.

Thank you, much better indeed.