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]

Message-ID: <09f084d2-6128-7f83-b2a5-cbe236b1678d@huaweicloud.com>
Date:   Wed, 18 Jan 2023 22:24:50 +0100
From:   Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To:     paulmck@...nel.org
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 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)
}

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)
}

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!)

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.

Best wishes,
jonas