[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8q/5hgXrvOp6vku@hirez.programming.kicks-ass.net>
Date: Fri, 20 Jan 2023 17:23:02 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Hernan Ponce de Leon <hernan.poncedeleon@...weicloud.com>
Cc: mingo@...hat.com, will@...nel.org, longman@...hat.com,
boqun.feng@...il.com, akpm@...l.org, arjan@...ux.intel.com,
tglx@...utronix.de, joel@...lfernandes.org, paulmck@...nel.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 02:55:25PM +0100, Hernan Ponce de Leon wrote:
> From: Hernan Ponce de Leon <hernanl.leon@...wei.com>
>
> Following the defition of data race in
> tools/memory-model/linux-kernel.cat the dartagnan tool
> https://github.com/hernanponcedeleon/Dat3M
> reported a race between mark_rt_mutex_waiters and rt_mutex_cmpxchg_release.
>
> Commit 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core")
> later removed in commit d0aa7a70bf03 ("futex_requeue_pi optimization")
> and reverted in commit bd197234b0a6
> ("Revert "futex_requeue_pi optimization"")
>
> The original commit introduced the data race.
>
> Cc: stable@...r.kernel.org # v2.6.18.x
> Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core")
> Signed-off-by: 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,
> owner | RT_MUTEX_HAS_WAITERS) != owner);
>
Can't we replace the whole of that function with:
set_bit(0, (unsigned long *)&lock->owner);
?
Powered by blists - more mailing lists