Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-22 Thread Thomas Gleixner
On Thu, 22 Nov 2018, Ingo Molnar wrote: > * Thomas Gleixner wrote: > > /* > > * Now maybe reload the debug registers and handle I/O bitmaps > > */ > > - if (unlikely(task_thread_info(next_p)->flags & _TIF_WORK_CTXSW_NEXT || > > -task_thread_info(prev_p)->flags & _TI

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-22 Thread Thomas Gleixner
On Thu, 22 Nov 2018, Jiri Kosina wrote: > On Wed, 21 Nov 2018, Andi Kleen wrote: > > > > + * This could be optimized by keeping track of the last > > > + * user task per cpu and avoiding the barrier when the task > > > + * is immediately scheduled back and the thread inb

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Ingo Molnar
* Thomas Gleixner wrote: > IBPB control is currently in switch_mm() to avoid issuing IBPB when > switching between tasks of the same process. > > But that's not covering the case of sandboxed tasks which get the > TIF_SPEC_IB flag set via seccomp. There the barrier is required when the > poten

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Jiri Kosina
On Wed, 21 Nov 2018, Andi Kleen wrote: > > +* This could be optimized by keeping track of the last > > +* user task per cpu and avoiding the barrier when the task > > +* is immediately scheduled back and the thread inbetween > > +* was a kernel threa

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Tim Chen
On 11/21/2018 12:14 PM, Thomas Gleixner wrote: > + * is immediately scheduled back and the thread inbetween s/inbetween/in between Tim

Re: [patch 17/24] x86/speculation: Move IBPB control out of switch_mm()

2018-11-21 Thread Andi Kleen
> + * This could be optimized by keeping track of the last > + * user task per cpu and avoiding the barrier when the task > + * is immediately scheduled back and the thread inbetween > + * was a kernel thread. It's dubious whether that'd be > +