[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae90e931-df19-9d60-610c-57dc34494d8e@redhat.com>
Date: Tue, 24 Jan 2023 11:04:58 -0500
From: Waiman Long <longman@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Hernan Ponce de Leon <hernan.poncedeleon@...weicloud.com>,
paulmck@...nel.org, Arjan van de Ven <arjan@...ux.intel.com>,
mingo@...hat.com, will@...nel.org, 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 1/24/23 10:52, Peter Zijlstra wrote:
> On Tue, Jan 24, 2023 at 10:42:24AM -0500, Waiman Long wrote:
>
>> I would suggest to do it as suggested by PeterZ. Instead of set_bit(),
>> however, it is probably better to use atomic_long_or() like
>>
>> atomic_long_or_relaxed(RT_MUTEX_HAS_WAITERS, (atomic_long_t *)&lock->owner)
> That function doesn't exist, atomic_long_or() is implicitly relaxed for
> not returning a value.
>
You are right. atomic_long_or() doesn't have variants like some others.
Cheers,
Longman
Powered by blists - more mailing lists