Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c

From: Rik van Riel
Date: Wed May 31 2017 - 08:44:38 EST


On Tue, 2017-05-30 at 21:05 -0700, Arjan van de Ven wrote:
> On 5/27/2017 9:56 AM, Andy Lutomirski wrote:
> > On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski <luto@xxxxxxxxxx>
> > wrote:
> > > On Sat, May 27, 2017 at 6:31 AM, kernel test robot
> > > <xiaolong.ye@xxxxxxxxx> wrote:
> > > >
> > > > FYI, we noticed the following commit:
> > > >
> > > > commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm:
> > > > Rework lazy TLB to track the actual loaded mm")
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git
> > > > x86/tlbflush_cleanup
> > >
> > > Ugh, there's an unpleasant interaction between this patch and
> > > intel_idle.ÂÂI suspect that the intel_idle code in question is
> > > either
> > > wrong or pointless, but I want to investigate further.ÂÂIngo, can
> > > you
> > > hold off on applying this patch?
> >
> > I think this is what's going on: intel_idle has an optimization and
> > sometimes calls leave_mm().ÂÂThis is a rather expensive way of
> > working
> > around x86 Linux's fairly weak lazy mm handling.ÂÂIt also abuses
> > the
> > whole switch_mm state machine.ÂÂIn particular, there's no guarantee
> > that the mm is actually lazy at the time.ÂÂThe old code didn't
> > care,
> > but the new code can oops.
> >
> > The short-term fix is to just reorder the code in leave_mm() to
> > avoid the OOPS.
>
> fwiw the reason the code is in intel_idle is to avoid tlb flush IPIs
> to idle cpus,
> once the cpu goes into a deep enough idle state.ÂÂIn the current
> linux code,
> that is done by no longer having the old TLB live on the CPU, by
> switching to the neutral
> kernel-only set of tlbs.
>
> If your proposed changes do that (avoid the IPI/wakeup), great!
> (if not, there should be a way to do that)

My patch moves the atomic write from the intel idle
path into the tlb invalidation path, and gets rid of
the IPI.

Shouldn't be too hard to get that on top of Andy's
patches, once those have settled.

https://patchwork.kernel.org/patch/9307541/