Re: [PATCH] x86/speculation: Update TIF_SPEC_IB before ibpb barrier

[Zhenzhong Duan]

On 2019/1/26 2:03, Thomas Gleixner wrote:
> On Fri, 25 Jan 2019, Thomas Gleixner wrote:
> > On Wed, 23 Jan 2019, Thomas Gleixner wrote:
> >
> > > On Fri, 18 Jan 2019, Zhenzhong Duan wrote:
> > >
> > > > When a task is set for updating TIF_SPEC_IB throuth SECCOMP by others
> > > > and it's scheduled in the first time, a stale TIF_SPEC_IB value is
> > > > picked in cond_ibpb(). This is due to TIF_SPEC_IB is updated later at
> > > > __switch_to_xtra().
> > > >
> > > > Add an extra call to speculation_ctrl_update_tif() to update it before
> > > > IBPB barrier.
> > >
> > > Errm. No. It adds that call to speculation_ctrl_update_tif() for every
> > > mm switch, most of the time for nothing.
> > >
> > > If at all, and we discussed that before and decided not to worry about it
> > > (because it gets fixed up on the next context switch), then you want to
> > > handle ibpb() from there:
> >
> > Actually we need to do that. It's not only the scheduled in first
> > problem. That whole thing might become completely stale in either
> > direction. Care to whip up a patch?
>
> Bah, nonsense. Brain was clearly still out for lunch and I confused IBPB
> and STIBP for a moment. cond_ibpb() is the thing issues in switch_mm() and
> that is not leaving a stale MSR around because we only write to it when we
> need the barrier. The bit is not stale because the barrier is only issued
> with the write. The bit has not to be cleared.
>
> So the only 'issue' what happens is that switch_to() either issues a
> barrier too much or misses one. That's really not a problem.

Ok, yes, the purpose of this patch is to avoid the one missed barrier.
Thanks for your reply.

Zhenzhong