All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kiryl Shutsemau" <kirill@shutemov.name>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v7 06/15] mm: add MM_CP_UFFD_RWP change_protection() flag
Date: Mon, 29 Jun 2026 12:27:05 +0000	[thread overview]
Message-ID: <20260629122706.484661F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629120749.566063-7-kirill@shutemov.name>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] MM_CP_UFFD_RWP silently destroys RWP protection and unmaps file-backed THPs.
--

commit 82229f238feb5343260ad7c878148b9a54c5893a
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

mm: add MM_CP_UFFD_RWP change_protection() flag

This patch introduces the MM_CP_UFFD_RWP and MM_CP_UFFD_RWP_RESOLVE flags
for userfaultfd RWP. The flags are wired through change_pte_range,
change_huge_pmd, and hugetlb_change_protection to install PROT_NONE with
a userfaultfd marker.

> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 8340c8b228c67..7dcc94e7bfd60 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
[ ... ]
> @@ -428,7 +441,7 @@ pgtable_split_needed(struct vm_area_struct *vma, unsigned long cp_flags)
>  	 * (e.g. 2M shmem) because file thp is handled differently when
>  	 * split by erasing the pmd so far.
>  	 */
> -	return (cp_flags & MM_CP_UFFD_WP) && !vma_is_anonymous(vma);
> +	return (cp_flags & (MM_CP_UFFD_WP | MM_CP_UFFD_RWP)) && !vma_is_anonymous(vma);
>  }

[Severity: High]
When a file-backed THP is split because pgtable_split_needed() returns true
here, __split_huge_pmd() clears the PMD and change_pmd_prepare() allocates
an empty PTE table with all none PTEs.

Then change_pte_range() processes these none PTEs, but it has this check:

mm/mprotect.c:change_pte_range() {
    ...
		} else if (pte_none(oldpte)) {
			/*
			 * Nobody plays with any none ptes besides
			 * userfaultfd when applying the protections.
			 */
			if (likely(!uffd_wp))
				continue;
    ...
}

Since uffd_wp is false during an MM_CP_UFFD_RWP operation, won't this cause
the none PTEs resulting from the THP split to be silently skipped?

This would leave the previously populated file-backed THP pages unmapped and
without any RWP protection markers. When they are accessed again, they might
fault back in with default permissions, bypassing the requested RWP tracking.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629120749.566063-1-kirill@shutemov.name?part=6

  reply	other threads:[~2026-06-29 12:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 12:07 [PATCH v7 00/15] userfaultfd: working set tracking for VM guest memory Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 01/15] mm: decouple protnone helpers from CONFIG_NUMA_BALANCING Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 02/15] mm: rename uffd-wp PTE bit macros to uffd Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 03/15] mm: rename uffd-wp PTE accessors " Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 04/15] userfaultfd: test uffd VMA flags through the vma_flags_t API Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 05/15] mm: add VM_UFFD_RWP VMA flag Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 06/15] mm: add MM_CP_UFFD_RWP change_protection() flag Kiryl Shutsemau
2026-06-29 12:27   ` sashiko-bot [this message]
2026-06-29 12:07 ` [PATCH v7 07/15] mm: preserve RWP marker across PTE rewrites Kiryl Shutsemau
2026-06-29 12:33   ` sashiko-bot
2026-06-29 16:02     ` Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 08/15] mm: handle VM_UFFD_RWP in khugepaged, rmap, and GUP Kiryl Shutsemau
2026-06-29 12:50   ` sashiko-bot
2026-06-29 12:07 ` [PATCH v7 09/15] userfaultfd: add UFFDIO_REGISTER_MODE_RWP and UFFDIO_RWPROTECT plumbing Kiryl Shutsemau
2026-06-29 12:40   ` sashiko-bot
2026-06-29 12:07 ` [PATCH v7 10/15] mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP Kiryl Shutsemau
2026-06-29 12:42   ` sashiko-bot
2026-06-29 12:07 ` [PATCH v7 11/15] mm/pagemap: add PAGE_IS_ACCESSED for RWP tracking Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 12/15] userfaultfd: add UFFD_FEATURE_RWP_ASYNC for async fault resolution Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 13/15] userfaultfd: add UFFDIO_SET_MODE for runtime sync/async toggle Kiryl Shutsemau
2026-06-29 12:07 ` [PATCH v7 14/15] selftests/mm: add userfaultfd RWP tests Kiryl Shutsemau
2026-06-29 12:46   ` sashiko-bot
2026-06-29 12:07 ` [PATCH v7 15/15] Documentation/userfaultfd: document RWP working set tracking Kiryl Shutsemau

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=20260629122706.484661F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kirill@shutemov.name \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.