[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1801062235490.2376@nanos>
Date: Sat, 6 Jan 2018 22:39:27 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
cc: Dave Hansen <dave.hansen@...el.com>,
"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
Konrad Rzeszutek Wilk <konrad@...nel.org>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Andi Kleen <ak@...ux.intel.com>,
David Woodhouse <dwmw@...zon.co.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/8] x86/spec_ctrl: Add sysctl knobs to enable/disable
SPEC_CTRL feature
On Sat, 6 Jan 2018, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> > On Sat, 6 Jan 2018, Dave Hansen wrote:
> >
> > > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > > >>>> .macro DISABLE_IBRS
> > > >>>> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> > > >>>> + testl $1, dynamic_ibrs
> > > >>> On every system call we end up hammering on this 'dynamic_ibrs'
> > > >>> variable. And it looks like it can be flipped via the IPI mechanism.
> > > >>>
> > > >>> Would it make sense for this to be per-cpu?
> > > >>
> > > >> It's probably better to either just make it __read_mostly or get the
> > > >> static branches that folks were suggesting actually working.
> > > >
> > > > I still wonder if this isn't just better as a boot command line
> > >
> > > It's simpler that way. But, ideally, we want to make it runtime
> > > switchable to match the implementation in the distros.
> >
> > Stop this silly argument please. The distros shipped lots of crap which we
> > dont want to have at all.
> >
> > I told you folks yesterday what I want to see and the sysctl thing is the
> > least on that list and it's not needed for getting the important thing -
> > the protection - to work.
>
> I agree. But this is what customers are told to inspect to see if they
> are impacted. And if in the future versions this goes away or such - they
> will freak out and cause needless escalations.
That's the result of distros cramming stuff into their kernels without
talking to us. It's their problem to explain that their customers.
We can talks about the sysctl _AFTER_ fixing the real issues.
Thanks,
tglx
Powered by blists - more mailing lists