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: <20230114173540.GC2948950@paulmck-ThinkPad-P17-Gen-1>
Date:   Sat, 14 Jan 2023 09:35:40 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Jonas Oberhauser <jonas.oberhauser@...wei.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "parri.andrea" <parri.andrea@...il.com>, 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 Sat, Jan 14, 2023 at 11:55:17AM -0500, Alan Stern wrote:
> On Fri, Jan 13, 2023 at 12:07:06PM -0800, Paul E. McKenney wrote:
> > What Alan said!  You could even have distinct partially overlapping
> > grace periods, as the Linux kernel actually does have courtesy of normal
> > grace periods via synchronize_rcu() and expedited grace periods via
> > synchronize_rcu_expedited().
> 
> Or just two different CPUs making overlapping calls to
> synchronize_rcu().

True, there could be two overlapping grace periods in that case.
If nothing else, one of those synchronize_rcu() calls could be preempted
for 500 milliseconds upon entry, thus overlapping many grace periods from
the viewpoint of the user.  Which is the viewpoint that LKMM should of
course take.

But because I had just been digging in the internals, I was taking
an implemntation-centric viewpoint.  From that viewpoint, there is at
most one normal grace period in flight at a time.  But even from that
viewpoint, there can also be a single independent expedited grace period
in flight at any given point in time, so partial overlap can happen even
from an implementation-centric viewpoint.

Which in no way negates or weakens your point, just letting you guys
know where I was coming from.  Because if things go as they normally do,
there will be a future discussion where my head will once again be deep
into the implementation.  ;-)

							Thanx, Paul