Re: kvm splat in mmu_spte_clear_track_bits
From: Jerome Glisse
Date: Tue Aug 29 2017 - 14:34:13 EST
On Tue, Aug 29, 2017 at 04:09:24PM +0200, Andrea Arcangeli wrote:
> Hello,
>
> On Tue, Aug 29, 2017 at 02:59:23PM +0200, Adam Borowski wrote:
> > On Tue, Aug 29, 2017 at 02:45:41PM +0200, Takashi Iwai wrote:
> > > [Put more people to Cc, sorry for growing too much...]
> >
> > We're all interested in 4.13.0 not crashing on us, so that's ok.
> >
> > > On Tue, 29 Aug 2017 11:19:13 +0200,
> > > Bernhard Held wrote:
> > > >
> > > > On 08/28/2017 at 06:56 PM, Nadav Amit wrote:
> > > > > Donât blame me for the TLB stuff... My money is on aac2fea94f7a .
> > > >
> > > > Amit, thanks for your courage to expose your patch!
> > > >
> > > > I'm more and more confident that aac2fea94f7a is the culprit. Maybe it
> > > > just accelerates the triggering of the splash. To be more sure the
> > > > kernel needs to be tested for a couple of days. It would be great if
> > > > others could assist in testing aac2fea94f7a.
> > >
> > > I'm testing with the revert for a while and it seems working.
> >
> > With nothing but aac2fea94f7a reverted, no explosions for me either.
>
> The aforementioned commit has 3 bugs.
>
> 1) mmu_notifier_invalidate_range cannot be used in replacement of
> mmu_notifier_invalidate_range_start/end. For KVM
> mmu_notifier_invalidate_range is a noop and rightfully so. A MMU
> notifier implementation has to implement either
> ->invalidate_range method or the invalidate_range_start/end
> methods, not both. And if you implement invalidate_range_start/end
> like KVM is forced to do, calling mmu_notifier_invalidate_range in
> common code is a noop for KVM.
>
> For those MMU notifiers that can get away only implementing
> ->invalidate_range, the ->invalidate_range is implicitly called by
> mmu_notifier_invalidate_range_end(). And only those secondary MMUs
> that share the same pagetable with the primary MMU (like AMD
> iommuv2) can get away only implementing ->invalidate_range.
>
> So all cases (THP on/off) are broken right now.
>
> To fix this is enough to replace mmu_notifier_invalidate_range with
> mmu_notifier_invalidate_range_start;mmu_notifier_invalidate_range_end. Either
> that or call multiple mmu_notifier_invalidate_page like before.
Kirill did regress invalidate_page as it use to be call outside the
spinlock and now it is call inside the spinlock thus reverting will
introduce back a regression.
You can refer to the thread about it:
https://lkml.org/lkml/2017/8/9/418
JÃrÃme