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: <20190829165407.GT4125@linux.ibm.com>
Date:   Thu, 29 Aug 2019 09:54:07 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Andy Lutomirski <luto@...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>
Subject: Re: [RFC v1 2/2] rcu/tree: Remove dynticks_nmi_nesting counter

On Thu, Aug 29, 2019 at 09:21:46AM -0700, Andy Lutomirski wrote:
> 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.

Yeah, PTI was quite annoying.  Still is, from what I can see.  :-/

> So I think we should just drop this :(

OK, thank you!  I will put a tag into -rcu marking its removal in case
it should prove useful whenever for whatever.

Joel, would you like to remove this, or would you rather that I did?
It is in code you are working with right now, so if I do it, I need to
wait until yours is finalized.  Which wouldn't be a problem.

						Thanx, Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ