Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1722690

Re: kvm splat in mmu_spte_clear_track_bits

From Jerome Glisse <jglisse@redhat.com>
Newsgroups linux.kernel
Subject Re: kvm splat in mmu_spte_clear_track_bits
Date 2017-08-29 20:40 +0200
Message-ID <ujTAC-6bu-7@gated-at.bofh.it> (permalink)
References (5 earlier) <ujvyi-80q-1@gated-at.bofh.it> <ujKQF-L5-3@gated-at.bofh.it> <ujOrg-33K-5@gated-at.bofh.it> <ujOrg-33K-3@gated-at.bofh.it> <ujPnm-3Ci-39@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: kvm splat in mmu_spte_clear_track_bits Adam Borowski <kilobyte@angband.pl> - 2017-08-25 15:20 +0200
  Re: kvm splat in mmu_spte_clear_track_bits Paolo Bonzini <pbonzini@redhat.com> - 2017-08-25 15:50 +0200
    Re: kvm splat in mmu_spte_clear_track_bits Adam Borowski <kilobyte@angband.pl> - 2017-08-27 14:40 +0200
      Re: kvm splat in mmu_spte_clear_track_bits Bernhard Held <berny156@gmx.de> - 2017-08-28 17:30 +0200
        Re: kvm splat in mmu_spte_clear_track_bits Bernhard Held <berny156@gmx.de> - 2017-08-28 18:10 +0200
          Re: kvm splat in mmu_spte_clear_track_bits Takashi Iwai <tiwai@suse.de> - 2017-08-28 18:20 +0200
        Re: kvm splat in mmu_spte_clear_track_bits Takashi Iwai <tiwai@suse.de> - 2017-08-28 18:10 +0200
        Re: kvm splat in mmu_spte_clear_track_bits Nadav Amit <nadav.amit@gmail.com> - 2017-08-28 19:00 +0200
          Re: kvm splat in mmu_spte_clear_track_bits Bernhard Held <berny156@gmx.de> - 2017-08-29 11:20 +0200
            Re: kvm splat in mmu_spte_clear_track_bits Adam Borowski <kilobyte@angband.pl> - 2017-08-29 15:10 +0200
              Re: kvm splat in mmu_spte_clear_track_bits Andrea Arcangeli <aarcange@redhat.com> - 2017-08-29 16:10 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 18:20 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Jerome Glisse <jglisse@redhat.com> - 2017-08-29 20:30 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Jerome Glisse <jglisse@redhat.com> - 2017-08-29 20:40 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 21:10 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Jerome Glisse <jglisse@redhat.com> - 2017-08-29 21:20 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 21:40 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Andrea Arcangeli <aarcange@redhat.com> - 2017-08-29 22:50 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-29 23:00 +0200
                Re: kvm splat in mmu_spte_clear_track_bits Michal Hocko <mhocko@kernel.org> - 2017-08-30 10:20 +0200
            Re: kvm splat in mmu_spte_clear_track_bits Nadav Amit <nadav.amit@gmail.com> - 2017-08-29 18:00 +0200
          Re: kvm splat in mmu_spte_clear_track_bits Mike Galbraith <efault@gmx.de> - 2017-08-29 15:00 +0200

csiph-web