On Sun, 30 Apr 2023 21:19:17 +0100 Lorenzo Stoakes <lstoakes@xxxxxxxxx> wrote: > We may still have inconsistent input parameters even if we choose not to > merge and the vma_merge() invariant checks are useful for checking this > with no production runtime cost (these are only relevant when > CONFIG_DEBUG_VM is specified). > > Therefore, perform these checks regardless of whether we merge. > > This is relevant, as a recent issue (addressed in commit "mm/mempolicy: > Correctly update prev when policy is equal on mbind") in the mbind logic > was only picked up in the 6.2.y stable branch where these assertions are > performed prior to determining mergeability. > > Had this remained the same in mainline this issue may have been picked up > faster, so moving forward let's always check them. > I'll scoot this into 6.4-rc, given the recent problems in this area. > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -960,17 +960,17 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > merge_next = true; > } > > + /* Verify some invariant that must be enforced by the caller. */ > + VM_WARN_ON(prev && addr <= prev->vm_start); > + VM_WARN_ON(curr && (addr != curr->vm_start || end > curr->vm_end)); > + VM_WARN_ON(addr >= end); Maybe converting to VM_WARN_ON_ONCE() would be kinder.
