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.
