Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-21 Thread Peter Zijlstra
On Thu, Mar 21, 2019 at 11:18:05AM -0700, h...@zytor.com wrote: > On March 21, 2019 10:25:05 AM PDT, Denys Vlasenko wrote: > >I did not see evidence of this. In my testing, > >POPF is always ~20 cycles, even if popped flags are identical to > >current state of flags. > > I think you will find

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-21 Thread Linus Torvalds
On Thu, Mar 21, 2019 at 10:25 AM Denys Vlasenko wrote: > > > > > But iirc pushf/popf isn't really that expensive - in fact I think it's > > pretty cheap when system flags don't change. > > I did not see evidence of this. In my testing, > POPF is always ~20 cycles, even if popped flags are

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-21 Thread hpa
On March 21, 2019 10:25:05 AM PDT, Denys Vlasenko wrote: >On 3/18/19 7:10 PM, Linus Torvalds wrote: >> On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra > wrote: >>> >>> How about I do a patch that schedules EFLAGS for both 32bit and >64bit, >>> mark this for backporting to infinity. >>> >>> And

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-21 Thread Denys Vlasenko
On 3/18/19 7:10 PM, Linus Torvalds wrote: On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra wrote: How about I do a patch that schedules EFLAGS for both 32bit and 64bit, mark this for backporting to infinity. And then at the end, after the objtool-ac bits land, I do a patch removing the EFLAGS

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-21 Thread hpa
On March 18, 2019 11:10:22 AM PDT, Linus Torvalds wrote: >On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra >wrote: >> >> How about I do a patch that schedules EFLAGS for both 32bit and >64bit, >> mark this for backporting to infinity. >> >> And then at the end, after the objtool-ac bits land, I

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-18 Thread Linus Torvalds
On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra wrote: > > How about I do a patch that schedules EFLAGS for both 32bit and 64bit, > mark this for backporting to infinity. > > And then at the end, after the objtool-ac bits land, I do a patch > removing the EFLAGS scheduling for x86_64. Sounds

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-18 Thread Peter Zijlstra
On Mon, Mar 18, 2019 at 06:36:57PM +0100, Peter Zijlstra wrote: > then I'd sleep much better if we make 32bit context switch EFLAGS. > Because, yes, x86_64 objtool validates a lot of the x86_32 code too, but > unless we have 100% coverage, there's always the chance an AC=1 escapes. How about I do

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-18 Thread Peter Zijlstra
On Mon, Mar 18, 2019 at 09:58:20AM -0700, Linus Torvalds wrote: > On Mon, Mar 18, 2019 at 8:54 AM Peter Zijlstra wrote: > > > > We rely on objtool to verify AC=1 doesn't escape. However there is no > > objtool support for x86_32, and thus we cannot guarantee the > > correctness of the 32bit code.

Re: [PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-18 Thread Linus Torvalds
On Mon, Mar 18, 2019 at 8:54 AM Peter Zijlstra wrote: > > We rely on objtool to verify AC=1 doesn't escape. However there is no > objtool support for x86_32, and thus we cannot guarantee the > correctness of the 32bit code. Absolutely not. This is just crazy. We had working SMAP long before

[PATCH 01/25] x86: Make SMAP 64-bit only

2019-03-18 Thread Peter Zijlstra
We rely on objtool to verify AC=1 doesn't escape. However there is no objtool support for x86_32, and thus we cannot guarantee the correctness of the 32bit code. Also; if you're running 32bit kernels on hardware with SMAP (which all should have LM support afaik) you're doing it wrong anyway.