Skip to content

Commit 1d538a0

Browse files
r-c-ngregkh
authored andcommitted
mm,madvise,hugetlb: check for 0-length range after end address adjustment
commit 2ede647 upstream. Add a sanity check to madvise_dontneed_free() to address a corner case in madvise where a race condition causes the current vma being processed to be backed by a different page size. During a madvise(MADV_DONTNEED) call on a memory region registered with a userfaultfd, there's a period of time where the process mm lock is temporarily released in order to send a UFFD_EVENT_REMOVE and let userspace handle the event. During this time, the vma covering the current address range may change due to an explicit mmap done concurrently by another thread. If, after that change, the memory region, which was originally backed by 4KB pages, is now backed by hugepages, the end address is rounded down to a hugepage boundary to avoid data loss (see "Fixes" below). This rounding may cause the end address to be truncated to the same address as the start. Make this corner case follow the same semantics as in other similar cases where the requested region has zero length (ie. return 0). This will make madvise_walk_vmas() continue to the next vma in the range (this time holding the process mm lock) which, due to the prev pointer becoming stale because of the vma change, will be the same hugepage-backed vma that was just checked before. The next time madvise_dontneed_free() runs for this vma, if the start address isn't aligned to a hugepage boundary, it'll return -EINVAL, which is also in line with the madvise api. From userspace perspective, madvise() will return EINVAL because the start address isn't aligned according to the new vma alignment requirements (hugepage), even though it was correctly page-aligned when the call was issued. Link: https://lkml.kernel.org/r/[email protected] Fixes: 8ebe0a5 ("mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs") Signed-off-by: Ricardo Cañuelo Navarro <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Cc: Florent Revest <[email protected]> Cc: Rik van Riel <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
1 parent 1ece4a9 commit 1d538a0

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

mm/madvise.c

+10-1
Original file line numberDiff line numberDiff line change
@@ -928,7 +928,16 @@ static long madvise_dontneed_free(struct vm_area_struct *vma,
928928
*/
929929
end = vma->vm_end;
930930
}
931-
VM_WARN_ON(start >= end);
931+
/*
932+
* If the memory region between start and end was
933+
* originally backed by 4kB pages and then remapped to
934+
* be backed by hugepages while mmap_lock was dropped,
935+
* the adjustment for hugetlb vma above may have rounded
936+
* end down to the start address.
937+
*/
938+
if (start == end)
939+
return 0;
940+
VM_WARN_ON(start > end);
932941
}
933942

934943
if (behavior == MADV_DONTNEED || behavior == MADV_DONTNEED_LOCKED)

0 commit comments

Comments
 (0)