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, 18 Jan 2023 16:11:47 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        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 18, 2023 at 10:24:50PM +0100, Jonas Oberhauser wrote:
> 
> 
> On 1/18/2023 10:12 PM, Paul E. McKenney wrote:
> 
> > The only difference between srcu_read_lock() and srcu_read_unlock()
> > on the one hand and srcu_down_read() and srcu_up_read() on the other
> > is that a matching pair of srcu_read_lock() and srcu_read_unlock()
> > must be running on the same task.  In contrast, srcu_down_read() and
> > srcu_up_read() are not subject to this constraint.
> > 
> > > What I was suggesting below is how to redefine "match" between read_down and
> > > read_up that work more like a cross-thread semaphore.
> > Understood, but what I don't understand is why not simply this:
> > 
> > let srcu-rscs-down = ([Srcu-down] ; (data | rf)* ; [Srcu-up]) & loc
> 
> Oh, I had thought that it should be more like a semaphore rather than just a
> cross-cpu mutex.
> 
> Here's an example of how what you are describing would be used:
> 
> P0{
>    idx = srcu_down(&ss);
>    store_release(done,1);
> }
> 
> P1{
>     while (! load_acquire(done));
>     srcu_up(&ss,idx)
> }

Exactly!!!

> What I was thinking of is more something like this:
> 
> P0{
>    idx1 = srcu_down(&ss);
>    srcu_up(&ss,idx1);
> }
> 
> P1{
>     idx2 = srcu_down(&ss);
>     srcu_up(&ss,idx2)
> }

And srcu_read_lock() and srcu_read_unlock() already do this.

> where the big difference to srcu_lock/unlock would be that if P0 and P1
> happened to get the same index -- which you could very well check or
> synchronize on -- that you would be guaranteed that the grace period only
> ends once *all* threads that are using this index have called up. (note that
> I believe that your implementation has this property, and some users may
> come to rely on it if they find out!)

They are permitted and encouraged to rely on the fact that
synchronize_srcu() waits until all pre-existing SRCU read-side critical
sections have completed, which I believe is quite close to what you
are saying.  But if they want to look at the return values from either
srcu_read_lock() or srcu_down_read(), they would be better off using
either get_state_synchronize_srcu() or start_poll_synchronize_srcu().

Huh.  I need to add a NUM_ACTIVE_SRCU_POLL_OLDSTATE, don't I?  I first
need to figure out what its value would be.

> If you want this latter kind of guarantee, then you need to do so something
> along the lines of what Alan or I wrote.
> 
> If all you need is the ability to use the first scenario, without any
> guarantee that if the index happened to be the same (or providing an API
> where you can do the down with a fixed index provided by P0) the grace
> period will extend, then what you propose should be right.
> 
> But from Alan's comments I had misunderstood that that wouldn't be the case.

"What do you need?"  "Well, what can be provided?"  ;-)

							Thanx, Paul