linux-kernel - Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 25 Jan 2023 20:45:44 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Jonas Oberhauser <jonas.oberhauser@...weicloud.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Jonas Oberhauser <jonas.oberhauser@...wei.com>,
        Peter Zijlstra <peterz@...radead.org>, will <will@...nel.org>,
        "boqun.feng" <boqun.feng@...il.com>, npiggin <npiggin@...il.com>,
        dhowells <dhowells@...hat.com>,
        "j.alglave" <j.alglave@....ac.uk>,
        "luc.maranget" <luc.maranget@...ia.fr>, akiyks <akiyks@...il.com>,
        dlustig <dlustig@...dia.com>, joel <joel@...lfernandes.org>,
        urezki <urezki@...il.com>,
        quic_neeraju <quic_neeraju@...cinc.com>,
        frederic <frederic@...nel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus
 test)

On Wed, Jan 25, 2023 at 03:33:08PM -0800, Paul E. McKenney wrote:
> Ah, and returning to the earlier question as to whether srcu_read_unlock()
> can use release semantics instead of smp_mb(), at the very least, this
> portion of the synchronize_srcu() function's header comment must change:
> 
> 	On systems with more than one CPU, when synchronize_srcu()
> 	returns, each CPU is guaranteed to have executed a full
> 	memory barrier since the end of its last corresponding SRCU
> 	read-side critical section whose beginning preceded the call
> 	to synchronize_srcu().

Yes, that would not be true.  But on the other hand, it would be true 
that each CPU is guaranteed to have executed a release memory barrier 
since the end of its last corresponding SRCU read-side critical section 
whose beginning preceded the call to synchronize_srcu(), _and_ the CPU 
executing synchronize_srcu() is guaranteed to have executed a full 
memory barrier after seeing the values from all those release stores.
This is not quite the same thing but it ought to be just as good.

> I don't know of any SRCU code that relies on this, but it would be good to
> check.	There used to (and might still) be RCU code relying on this, which
> is why this sentence was added to the header comment in the first place.

If there is code relying on that guarantee, it ought to work just as 
well by relying on the modified guarantee.

Of course, there might be code relying on a guarantee that 
srcu_read_unlock() executes a full memory barrier.  This guarantee would 
certainly no longer hold.  But as I understand it, this guarantee was 
never promised by the SRCU subsystem.

Alan