Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 20 Jan 2023 07:54:39 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Arjan van de Ven <arjan@linux.intel.com>
Cc:     Hernan Ponce de Leon <hernan.poncedeleon@huaweicloud.com>,
        peterz@infradead.org, mingo@redhat.com, will@kernel.org,
        longman@redhat.com, boqun.feng@gmail.com, akpm@osdl.org,
        tglx@linutronix.de, joel@joelfernandes.org,
        stern@rowland.harvard.edu, diogo.behrens@huawei.com,
        jonas.oberhauser@huawei.com, linux-kernel@vger.kernel.org,
        Hernan Ponce de Leon <hernanl.leon@huawei.com>,
        stable@vger.kernel.org
Subject: Re: [PATCH] Fix data race in mark_rt_mutex_waiters
Message-ID: <20230120155439.GI2948950@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20230120135525.25561-1-hernan.poncedeleon@huaweicloud.com>
 <562c883b-b2c3-3a27-f045-97e7e3281e0b@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <562c883b-b2c3-3a27-f045-97e7e3281e0b@linux.intel.com>
Precedence: bulk

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@huawei.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