Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 28 Mar 2022 15:22:10 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        syzbot <syzbot+6bde52d89cfdf9f61425@syzkaller.appspotmail.com>,
        david@redhat.com, frankja@linux.ibm.com, imbrenda@linux.ibm.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com, vkuznets@redhat.com,
        wanpengli@tencent.com, will@kernel.org,
        Linux-MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [syzbot] WARNING in kvm_mmu_notifier_invalidate_range_start (2)
Message-ID: <YkHSopxM7oGb1Nhc@google.com>
References: <000000000000b6df0f05dab7e92c@google.com>
 <33b6fb1d-b35c-faab-4737-01427c48d09d@redhat.com>
 <6730ea89-8d85-bf30-28e5-01ca7ebdacea@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6730ea89-8d85-bf30-28e5-01ca7ebdacea@oracle.com>
Precedence: bulk

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.