linux-kernel - Re: [PATCH tip/core/rcu 13/22] rcu: Fix grace-period hangs due to race with CPU offline

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180628082653.GX2494@hirez.programming.kicks-ass.net>
Date:   Thu, 28 Jun 2018 10:26:53 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...nel.org,
        jiangshanlai@...il.com, dipankar@...ibm.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
        dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
        oleg@...hat.com, joel@...lfernandes.org
Subject: Re: [PATCH tip/core/rcu 13/22] rcu: Fix grace-period hangs due to
 race with CPU offline

On Wed, Jun 27, 2018 at 10:13:34PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 07:51:34PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 27, 2018 at 08:57:21AM -0700, Paul E. McKenney wrote:
> > > > Another variant, which simply skips the wakeup whever ran on an offline
> > > > CPU, relying on the wakeup from rcutree_migrate_callbacks() right after
> > > > the CPU really is dead.
> > > 
> > > Cute!  ;-)
> > > 
> > > And a much smaller change.
> > > 
> > > However, this means that if someone indirectly and erroneously causes
> > > rcu_report_qs_rsp() to be invoked from an offline CPU, the result is an
> > > intermittent and difficult-to-debug grace-period hang.  A lockdep splat
> > > whose stack trace directly implicates the culprit is much better.
> > 
> > How so? We do an unconditional wakeup right after finding the offline
> > cpu dead. There is only very limited code between offline being true and
> > the CPU reporting in dead.
> 
> I am thinking more generally than this particular patch.  People
> sometimes invoke things from places they shouldn't, for example, the
> situation leading to your patch that allows use of RCU much earlier in
> the CPU-online process.  It is nicer to get a splat in those situations
> than a silent hang.

The rcu_rnp_online_cpus() thing would catch that, right? The public RCU
API isn't that big, and should already complain afaict.