[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eccd473b-d3d6-3fe2-69c2-69b69729f721@zytor.com>
Date: Tue, 14 Jun 2016 13:54:25 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Lukasz Anaczkowski <lukasz.anaczkowski@...el.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
tglx@...utronix.de, mingo@...hat.com, ak@...ux.intel.com,
kirill.shutemov@...ux.intel.com, mhocko@...e.com,
akpm@...ux-foundation.org, harish.srinivasappa@...el.com,
lukasz.odzioba@...el.com, grzegorz.andrejczuk@...el.com,
lukasz.daniluk@...el.com
Subject: Re: [PATCH v2] Linux VM workaround for Knights Landing A/D leak
On 06/14/16 13:47, Borislav Petkov wrote:
> On Tue, Jun 14, 2016 at 01:20:06PM -0700, H. Peter Anvin wrote:
>> static_cpu_has_bug() should turn into 5-byte NOP in the common (bugless)
>> case.
>
> Yeah, it does. I looked at the asm.
>
> I wasn't 100% sure because I vaguely remember gcc reordering things in
> some pathological case but I'm most likely remembering wrong because if
> it were doing that, then the whole nopping out won't work. F'get about
> it. :)
>
There was that. It is still possible that we end up with NOP a JMP
right before another JMP; we could perhaps make the patching code
smarter and see if we have a JMP immediately after.
-hpa
Powered by blists - more mailing lists