From: Andrew Morton <akpm@linux-foundation.org>
To: "Ricardo Cañuelo Navarro" <rcn@igalia.com>
Cc: riel@surriel.com, linux-mm@kvack.org, stable@vger.kernel.org,
kernel-dev@igalia.com, revest@google.com
Subject: Re: [PATCH] mm,madvise,hugetlb: check for 0-length range after end address adjustment
Date: Fri, 31 Jan 2025 14:23:21 -0800 [thread overview]
Message-ID: <20250131142321.632a9468529d3267abe641af@linux-foundation.org> (raw)
In-Reply-To: <20250131143749.1435006-1-rcn@igalia.com>
On Fri, 31 Jan 2025 15:37:49 +0100 Ricardo Cañuelo Navarro <rcn@igalia.com> wrote:
> 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.
>
> ...
>
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -933,7 +933,9 @@ static long madvise_dontneed_free(struct vm_area_struct *vma,
> */
> end = vma->vm_end;
> }
> - VM_WARN_ON(start >= end);
> + if (start == end)
> + return 0;
> + VM_WARN_ON(start > end);
> }
Perhaps add a comment telling the user how this situation can come about?
next prev parent reply other threads:[~2025-01-31 22:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 14:37 Ricardo Cañuelo Navarro
2025-01-31 14:58 ` Ricardo Cañuelo Navarro
2025-01-31 22:23 ` Andrew Morton [this message]
2025-02-03 7:14 ` Ricardo Cañuelo Navarro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250131142321.632a9468529d3267abe641af@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=kernel-dev@igalia.com \
--cc=linux-mm@kvack.org \
--cc=rcn@igalia.com \
--cc=revest@google.com \
--cc=riel@surriel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox