Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <09f084d2-6128-7f83-b2a5-cbe236b1678d@huaweicloud.com>
Date:   Wed, 18 Jan 2023 22:24:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus
 test)
To:     paulmck@kernel.org
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        Andrea Parri <parri.andrea@gmail.com>,
        Jonas Oberhauser <jonas.oberhauser@huawei.com>,
        Peter Zijlstra <peterz@infradead.org>, will <will@kernel.org>,
        "boqun.feng" <boqun.feng@gmail.com>, npiggin <npiggin@gmail.com>,
        dhowells <dhowells@redhat.com>,
        "j.alglave" <j.alglave@ucl.ac.uk>,
        "luc.maranget" <luc.maranget@inria.fr>, akiyks <akiyks@gmail.com>,
        dlustig <dlustig@nvidia.com>, joel <joel@joelfernandes.org>,
        urezki <urezki@gmail.com>,
        quic_neeraju <quic_neeraju@quicinc.com>,
        frederic <frederic@kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>
References: <Y8aKlNY4Z0z2Yqs0@andrea>
 <20230117151416.GI2948950@paulmck-ThinkPad-P17-Gen-1>
 <Y8bFMgDSUZymXUsS@rowland.harvard.edu>
 <20230117174308.GK2948950@paulmck-ThinkPad-P17-Gen-1>
 <Y8cBypKx4gM3wBJa@rowland.harvard.edu>
 <20230118035041.GQ2948950@paulmck-ThinkPad-P17-Gen-1>
 <Y8gjUKoHxqR9+7Hx@rowland.harvard.edu>
 <3dabbcfb-858c-6aa0-6824-05b8cc8e9cdb@gmail.com>
 <20230118201918.GI2948950@paulmck-ThinkPad-P17-Gen-1>
 <a5637181-1675-7973-489c-e5d24cbd25c2@huaweicloud.com>
 <20230118211201.GL2948950@paulmck-ThinkPad-P17-Gen-1>
From:   Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
In-Reply-To: <20230118211201.GL2948950@paulmck-ThinkPad-P17-Gen-1>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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