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]

Message-ID: <c1a03870-43dd-5837-0a09-1ba3a996ec59@huaweicloud.com>
Date:   Mon, 23 Jan 2023 21:02:30 +0100
From:   Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To:     Alan Stern <stern@...land.harvard.edu>,
        "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Hernan Ponce de Leon <hernan.poncedeleon@...weicloud.com>,
        Arjan van de Ven <arjan@...ux.intel.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,
        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/23/2023 6:34 PM, Alan Stern wrote:
> On Mon, Jan 23, 2023 at 08:40:14AM -0800, Paul E. McKenney wrote:
>> In the case, the value read is passed into cmpxchg_relaxed(), which
>> checks the value against memory.  In this case, as Arjan noted, the only
>> compiler-and-silicon difference between data_race() and READ_ONCE()
>> is that use of data_race() might allow the compiler to do things like
>> tear the load, thus forcing the occasional spurious cmpxchg_relaxed()
>> failure.
> Is it possible in theory for a torn load to cause a spurious
> cmpxchg_relaxed() success?  Or would that not matter here?

Note that in this example there are no memory accesses between the read 
and the CAS.
So if the cmpxchg succeeds, what you non-atomically read must be exactly 
the value that is read by the cmpxchg, and you could pretend that the 
torn read happened at the same time as the cmpxchg.

This "pretend" part requires that there are no other events in the 
middle, otherwise you could be violating some ordering constraint 
between those events and the torn reads. Otherwise you might get some 
issues. E.g., you might read a sequence count of 259 from reading the 
lower half when the count is 3 and the upper half when the count is 256, 
and then do the CAS when the sequence count is 259, so if you had two 
peeks at sequence-count-protected data between that read and the CAS you 
might see different states despite the CAS succeeding.

have fun, jonas