linux-kernel - Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi

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: <CALCETrWNPOOdTrFabTDd=H7+wc6xJ9rJceg6OL1S0rTV5pfSsA@mail.gmail.com>
Date:   Thu, 29 Aug 2019 09:21:46 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     paulmck@...nel.org
Cc:     Joel Fernandes <joel@...lfernandes.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Josh Triplett <josh@...htriplett.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        rcu@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        Andrew Lutomirski <luto@...nel.org>
Subject: Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter

On Thu, Aug 29, 2019 at 9:10 AM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
>
> [ . . . ]
>
> > Paul, do we also nuke rcu_eqs_special_set()?  Currently I don't see anyone
> > using it. And also remove the bottom most bit of dynticks?
> >
> > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or idle
> > CPUs are the moment?
> >
> > All of this was introduced in:
> > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")
>
> Adding Andy Lutomirski on CC.
>
> Andy, is this going to be used in the near term, or should we just get
> rid of it?
>

Let's get rid of it.  I'm not actually convinced it *can* be used as designed.

For those who forgot the history or weren't cc'd on all of it: I had
this clever idea about how we could reduce TLB flushes.  I implemented
some of it (but not the part that would have used this RCU feature),
and it exploded in nasty and subtle ways.  This caused me to learn
that speculative TLB fills were a problem that I had entirely failed
to account for.  Then PTI happened and thoroughly muddied the water.

So I think we should just drop this :(