linux-kernel - Re: [RFC][PATCH 0/4] locking: Add/convert context analysis bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANpmjNNGwkb8p7Mo1sgEVg2ttRtmOOeSrHSmnHbQijpYnL7Y7g@mail.gmail.com>
Date: Fri, 23 Jan 2026 21:15:00 +0100
From: Marco Elver <elver@...gle.com>
To: Bart Van Assche <bvanassche@....org>
Cc: Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org, 
	bigeasy@...utronix.de, mingo@...nel.org, tglx@...utronix.de, will@...nel.org, 
	boqun.feng@...il.com, longman@...hat.com, hch@....de, rostedt@...dmis.org, 
	llvm@...ts.linux.dev
Subject: Re: [RFC][PATCH 0/4] locking: Add/convert context analysis bits

On Fri, 23 Jan 2026 at 19:58, Bart Van Assche <bvanassche@....org> wrote:
>
> On 1/23/26 3:15 AM, Peter Zijlstra wrote:
> > --- a/include/linux/rtmutex.h
> > +++ b/include/linux/rtmutex.h
> > @@ -41,7 +41,7 @@ struct rt_mutex_base {
> >    */
> >   static inline bool rt_mutex_base_is_locked(struct rt_mutex_base *lock)
> >   {
> > -     return READ_ONCE(lock->owner) != NULL;
> > +     return data_race(READ_ONCE(lock->owner) != NULL);
> >   }
> >
> >   #ifdef CONFIG_RT_MUTEXES
> > @@ -49,7 +49,7 @@ static inline bool rt_mutex_base_is_lock
> >
> >   static inline struct task_struct *rt_mutex_owner(struct rt_mutex_base *lock)
> >   {
> > -     unsigned long owner = (unsigned long) READ_ONCE(lock->owner);
> > +     unsigned long owner = (unsigned long) data_race(READ_ONCE(lock->owner));
> >
> >       return (struct task_struct *) (owner & ~RT_MUTEX_HAS_WAITERS);
> >   }
> Marco, shouldn't lock context analysis be disabled for all READ_ONCE()
> invocations? I expect that all code that uses READ_ONCE() to read a
> structure member annotated with __guarded_by() will have to be annotated
> with data_race(). Shouldn't the data_race() invocation be moved into the
> READ_ONCE() definition?

Unclear, guarded variables accessed with READ_ONCE() do not
necessarily imply access without said lock is safe.

Second, a READ_ONCE() paired with another marked primitive never
results in a data race, and using data_race() actually prohibits KCSAN
from detecting real data races if any would be introduced, but we're
not expecting any.

In the above case, if there aren't actually any data races, the
data_race() addition does look odd.
Perhaps context_unsafe(READ_ONCE(..)) would be more appropriate if
there's no actual data race. That will signal context analysis this is
safe, and if there are any real data races introduced here (e.g. by a
concurrent plain write or such), we'd learn about it if KCSAN detects
it.