linux-kernel - Re: [PATCH] Fix data race in mark_rt_mutex

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 20 Jan 2023 07:54:39 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Arjan van de Ven <arjan@...ux.intel.com>
Cc:     Hernan Ponce de Leon <hernan.poncedeleon@...weicloud.com>,
        peterz@...radead.org, mingo@...hat.com, will@...nel.org,
        longman@...hat.com, boqun.feng@...il.com, akpm@...l.org,
        tglx@...utronix.de, joel@...lfernandes.org,
        stern@...land.harvard.edu, diogo.behrens@...wei.com,
        jonas.oberhauser@...wei.com, linux-kernel@...r.kernel.org,
        Hernan Ponce de Leon <hernanl.leon@...wei.com>,
        stable@...r.kernel.org
Subject: Re: [PATCH] Fix data race in mark_rt_mutex_waiters

On Fri, Jan 20, 2023 at 06:58:20AM -0800, Arjan van de Ven wrote:
> On 1/20/2023 5:55 AM, Hernan Ponce de Leon wrote:
> > From: Hernan Ponce de Leon <hernanl.leon@...wei.com>
> > 
> 
> >   kernel/locking/rtmutex.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> > index 010cf4e6d0b8..7ed9472edd48 100644
> > --- a/kernel/locking/rtmutex.c
> > +++ b/kernel/locking/rtmutex.c
> > @@ -235,7 +235,7 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock)
> >   	unsigned long owner, *p = (unsigned long *) &lock->owner;
> >   	do {
> > -		owner = *p;
> > +		owner = READ_ONCE(*p);
> >   	} while (cmpxchg_relaxed(p, owner,
> 
> 
> I don't see how this makes any difference at all.
> *p can be read a dozen times and it's fine; cmpxchg has barrier semantics for compilers afaics

Doing so does suppress a KCSAN warning.  You could also use data_race()
if it turns out that the volatile semantics would prevent a valuable
compiler optimization.

							Thanx, Paul