Re: [syzbot] WARNING in kvm_mmu_notifier_invalidate_range_start (2)

[Sean Christopherson]

On Mon, Mar 21, 2022, Maciej S. Szmigiero wrote:
> On 21.03.2022 12:01, Paolo Bonzini wrote:
> > On 3/21/22 11:25, syzbot wrote:
> > diff --git a/mm/mremap.c b/mm/mremap.c
> > index 002eec83e91e..0e175aef536e 100644
> > --- a/mm/mremap.c
> > +++ b/mm/mremap.c
> > @@ -486,6 +486,9 @@ unsigned long move_page_tables(struct vm_area_struct
> >       pmd_t *old_pmd, *new_pmd;
> >       pud_t *old_pud, *new_pud;
> > 
> > +    if (!len)
> > +        return 0;
> > +
> >       old_end = old_addr + len;
> >       flush_cache_range(vma, old_addr, old_end);
> > 
> > but there are several other ways to fix this elsewhere in the call chain:
> > 
> > - check for old_len == 0 somewhere in mremap_to
> > 
> > - skip the call in __mmu_notifier_invalidate_range_start and
> >   __mmu_notifier_invalidate_range_end, if people agree not to play
> >   whack-a-mole with the callers of mmu_notifier_invalidate_range_*.
> > 
> > - remove the warning in KVM
> 
> This probably depends whether it is actually legal to call MMU notifiers
> with a zero range, the first time this warning triggered it was the caller
> that was fixed [1].
> 
> By the way, the warning-on-zero-range was added during memslots patch set
> review process [2], but I think it ultimately does make sense.

My vote is to play whack-a-mole.  This particular flavor isn't all that interesting,
but the HugeTLB bug was a genuine off-by-one error.  Given the low (so far) number
of unique reports, IMO the benefits of detecting buggy callers outweighs the cost of
having to fix/address benign paths where userspace is doing something silly.