From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Tal Zussman <tz2294@columbia.edu>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Mike Rapoport" <rppt@kernel.org>, "Peter Xu" <peterx@redhat.com>,
"James Houghton" <jthoughton@google.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Balbir Singh" <balbirs@nvidia.com>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Jann Horn" <jannh@google.com>,
"Pedro Falcato" <pfalcato@suse.de>,
"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
"Andrei Vagin" <avagin@gmail.com>,
"Stephen Rothwell" <sfr@canb.auug.org.au>,
"Arnd Bergmann" <arnd@arndb.de>,
"Muhammad Usama Anjum" <usama.anjum@arm.com>,
"David Hildenbrand" <david@kernel.org>, "Zi Yan" <ziy@nvidia.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Joshua Hahn" <joshua.hahnjy@gmail.com>,
"Byungchul Park" <byungchul@sk.com>,
"Gregory Price" <gourry@gourry.net>,
"Ying Huang" <ying.huang@linux.alibaba.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Nico Pache" <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Dev Jain" <dev.jain@arm.com>, "Barry Song" <baohua@kernel.org>,
"Lance Yang" <lance.yang@linux.dev>,
"Usama Arif" <usama.arif@linux.dev>,
"Kiryl Shutsemau" <kas@kernel.org>,
"Chris Down" <chris@chrisdown.name>,
"Muchun Song" <muchun.song@linux.dev>,
"Oscar Salvador" <osalvador@suse.de>,
"Mikołaj Lenczewski" <miko.lenczewski@arm.com>,
"Michal Hocko" <mhocko@suse.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 12/12] mm/userfaultfd: check hugetlb end alignment in UFFDIO_UNREGISTER pre-scan
Date: Thu, 12 Nov 2026 19:52:38 +0000 [thread overview]
Message-ID: <avYVPp7fHNg8WSUB@gremlin> (raw)
In-Reply-To: <20261111-uffd-state-fixes-v1-12-00713d368976@columbia.edu>
hugetlb vs userfaultfd is a bit like the alien vs. predator of worst mm features
of all time (TM)
On Wed, Nov 11, 2026 at 12:55:20PM -0500, Tal Zussman wrote:
> UFFDIO_REGISTER and UFFDIO_UNREGISTER both scan the VMAs of the range
> before changing anything. For a hugetlb VMA, userfaultfd_register()
> rejects a range whose start or end is not huge page aligned there.
> However, userfaultfd_unregister() only checks the start.
>
> An unaligned end only fails later, when vma_modify_flags_uffd() cannot
> split the VMA there. At that point, userfaultfd_clear_vma() already
> cleared the WP or RWP protection. The ioctl returns -EINVAL and the VMA
> stays registered, but accesses to its pages are no longer reported. This
> requires a caller passing a misaligned range.
>
> To fix it, check the end of a registered VMA in the pre-scan as well.
> The ioctl still returns -EINVAL, but no longer unregisters the VMAs
> before the misaligned one first.
>
> Fixes: cab350afcbc9 ("userfaultfd: hugetlbfs: allow registration of ranges containing huge pages")
> Fixes: f369b07c8614 ("mm/uffd: reset write protection when unregister with wp-mode")
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
> ---
> mm/userfaultfd.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index bf42fabb5afd..c0076c8b4e9d 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -3983,6 +3983,18 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx,
> if (!vma_can_userfault(cur, cur->vm_flags, wp_async))
> goto out_unlock;
>
> + /*
> + * A range ending inside a registered hugetlb vma must end
> + * huge page aligned, as in userfaultfd_register().
> + */
Hmm I think this is more or less saying what the code is doing :) so I think
unnecessary. Maybe worth using the words 'cursed' and 'eldrich' here to describe
what's going on? Or possibly just e.g.:
/* See check in userfaultfd_register(). */
> + if (cur->vm_userfaultfd_ctx.ctx && vma_is_hugetlb(cur) &&
This first check is pretty horrid to spell out loud, maybe do something like:
do {
const struct userfaultfd_ctx *vma_ctx = cur->vm_userfaultfd_ctx.ctx;
...
if (vma_ctx && vma_is_hugetlb(cur) && end <= cur->vm_end &&
end > cur->vm_start) {
...
}
> + end <= cur->vm_end && end > cur->vm_start) {
> + unsigned long vma_hpagesize = vma_kernel_pagesize(cur);
Could be const?
Also is vma_kernel_pagesize() right? If the VMA is hugetlb, then that'll end up
as hugetlb_vm_op_pagesize() which is huge_page_size(hstate_vma()), but it seems
userfaultfd is full of this crap and yeah ok. Fine :)
> +
> + if (end & (vma_hpagesize - 1))
Could do:
if (!IS_ALIGNED(end, vma_hpagesize))
Instead?
> + goto out_unlock;
> + }
> +
> found = true;
> } for_each_vma_range(vmi, cur, end);
> VM_WARN_ON_ONCE(!found);
>
> --
> 2.39.5
>
--
Cheers, Lorenzo
prev parent reply other threads:[~2026-11-12 19:52 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 17:55 [PATCH 00/12] userfaultfd: assorted fixes (part 1) Tal Zussman
2026-11-11 17:55 ` [PATCH 01/12] userfaultfd: use anonymous memory for UFFDIO_ZEROPAGE on private file mappings Tal Zussman
2026-11-12 18:05 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 02/12] userfaultfd: refuse UFFDIO_MOVE into a non-present huge destination PMD Tal Zussman
2026-11-12 17:56 ` sashiko-bot
2026-11-12 18:07 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 03/12] fs/proc/task_mmu: downgrade writable migration entries in PAGEMAP_SCAN write-protect Tal Zussman
2026-11-12 18:34 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 04/12] mm/migrate: keep the uffd bit when restoring a writable migration entry Tal Zussman
2026-11-12 18:44 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 05/12] fs/proc/task_mmu: write-protect device-private THPs in PAGEMAP_SCAN Tal Zussman
2026-11-12 19:34 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 06/12] mm/huge_memory: build the moved huge zero PMD from the destination VMA Tal Zussman
2026-11-11 19:12 ` Kiryl Shutsemau
2026-11-12 17:57 ` sashiko-bot
2026-11-11 17:55 ` [PATCH 07/12] mm/mremap: resolve uffd state when the context is dropped, not during the move Tal Zussman
2026-11-11 19:20 ` Kiryl Shutsemau
2026-11-11 22:39 ` Tal Zussman
2026-11-12 11:44 ` Lorenzo Stoakes (ARM)
2026-11-12 16:00 ` Tal Zussman
2026-11-12 17:57 ` sashiko-bot
2026-11-11 17:55 ` [PATCH 08/12] mm/migrate_device: do not migrate a uffd-protected zero page Tal Zussman
2026-11-11 17:55 ` [PATCH 09/12] mm/madvise: let a guard marker carry the uffd-wp bit Tal Zussman
2026-11-12 11:21 ` Lorenzo Stoakes (ARM)
2026-11-12 16:06 ` Tal Zussman
2026-11-11 17:55 ` [PATCH 10/12] mm: set the uffd-wp bit on a guard marker when write-protecting Tal Zussman
2026-11-12 11:43 ` Lorenzo Stoakes (ARM)
2026-11-11 17:55 ` [PATCH 11/12] mm/madvise: send UFFD_EVENT_REMOVE when installing guard regions Tal Zussman
2026-11-11 19:25 ` Kiryl Shutsemau
2026-11-11 23:21 ` Tal Zussman
2026-11-12 9:40 ` Jose A. Perez de Azpillaga
2026-11-12 11:57 ` Kiryl Shutsemau
2026-11-12 11:03 ` Lorenzo Stoakes (ARM)
2026-11-12 11:06 ` Lorenzo Stoakes (ARM)
2026-11-12 15:56 ` Tal Zussman
2026-11-12 17:57 ` sashiko-bot
2026-11-11 17:55 ` [PATCH 12/12] mm/userfaultfd: check hugetlb end alignment in UFFDIO_UNREGISTER pre-scan Tal Zussman
2026-11-12 19:52 ` Lorenzo Stoakes (ARM) [this message]
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=avYVPp7fHNg8WSUB@gremlin \
--to=ljs@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=avagin@gmail.com \
--cc=balbirs@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=chris@chrisdown.name \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=jthoughton@google.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=miko.lenczewski@arm.com \
--cc=mirq-linux@rere.qmqm.pl \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sfr@canb.auug.org.au \
--cc=surenb@google.com \
--cc=tz2294@columbia.edu \
--cc=usama.anjum@arm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.