Date:   Wed, 25 Jan 2023 07:05:20 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
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>
Subject: Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus
 test)
Message-ID: <20230125150520.GG2948950@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20230124162253.GL2948950@paulmck-ThinkPad-P17-Gen-1>
 <3e5020c2-0dd3-68a6-9b98-5a7f57ed7733@huaweicloud.com>
 <20230124172647.GN2948950@paulmck-ThinkPad-P17-Gen-1>
 <2788294a-972e-acbc-84ce-25d2bb4d26d6@huaweicloud.com>
 <20230124221524.GV2948950@paulmck-ThinkPad-P17-Gen-1>
 <Y9BdNVk2LQiUYABS@rowland.harvard.edu>
 <20230124225449.GY2948950@paulmck-ThinkPad-P17-Gen-1>
 <Y9CL8LBz+/mbbD00@rowland.harvard.edu>
 <20230125022019.GB2948950@paulmck-ThinkPad-P17-Gen-1>
 <cedf3a39-12cd-1cb1-ad5a-7c10768cee40@huaweicloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cedf3a39-12cd-1cb1-ad5a-7c10768cee40@huaweicloud.com>
Precedence: bulk

On Wed, Jan 25, 2023 at 02:10:08PM +0100, Jonas Oberhauser wrote:
> 
> 
> On 1/25/2023 3:20 AM, Paul E. McKenney wrote:
> > On Tue, Jan 24, 2023 at 08:54:56PM -0500, Alan Stern wrote:
> > > On Tue, Jan 24, 2023 at 02:54:49PM -0800, Paul E. McKenney wrote:
> > > > On Tue, Jan 24, 2023 at 05:35:33PM -0500, Alan Stern wrote:
> > > > > Can you be more explicit?  Exactly what guarantees does the kernel
> > > > > implementation make that can't be expressed in LKMM?
> > > > I doubt that I will be able to articulate it very well, but here goes.
> > > > 
> > > > Within the Linux kernel, the rule for a given RCU "domain" is that if
> > > > an event follows a grace period in pretty much any sense of the word,
> > > > then that event sees the effects of all events in all read-side critical
> > > > sections that began prior to the start of that grace period.
> > > > 
> > > > Here the senses of the word "follow" include combinations of rf, fr,
> > > > and co, combined with the various acyclic and irreflexive relations
> > > > defined in LKMM.
> > > The LKMM says pretty much the same thing.  In fact, it says the event
> > > sees the effects of all events po-before the unlock of (not just inside)
> > > any read-side critical section that began prior to the start of the
> > > grace period.
> > > 
> > > > > And are these anything the memory model needs to worry about?
> > > > Given that several people, yourself included, are starting to use LKMM
> > > > to analyze the Linux-kernel RCU implementations, maybe it does.
> > > > 
> > > > Me, I am happy either way.
> > > Judging from your description, I don't think we have anything to worry
> > > about.
> > Sounds good, and let's proceed on that assumption then.  We can always
> > revisit later if need be.
> > 
> > 							Thanx, Paul
> 
> FWIW, I currently don't see a need for either RCU nor "base" LKMM to have
> this kind of guarantee.

In the RCU case, it is because it is far easier to provide this guarantee,
even though it is based on hardware and compilers rather than LKMM,
than it would be to explain to some random person why the access that
is intuitively clearly after the grace period can somehow come before it.

> But I'm curious for why it doesn't exist in LKMM -- is it because of Alpha
> or some other issues that make it hard to guarantee (like a compiler merging
> two threads and optimizing or something?), or is it simply that it seemed
> like a complicated guarantee with no discernible upside, or something else?

Because to the best of my knowledge, no one has ever come up with a
use for 2+2W and friends that isn't better handled by some much more
straightforward pattern of accesses.  So we did not guarantee it in LKMM.

Yes, you could argue that my "ease of explanation" paragraph above is
a valid use case, but I am not sure that this is all that compelling of
an argument.  ;-)

							Thanx, Paul