From: sashiko-bot@kernel.org
To: "Carlos López" <clopez@suse.de>, kvm@vger.kernel.org, linux-mm@kvack.org
Cc: linux-s390@vger.kernel.org, seanjc@google.com,
pbonzini@redhat.com, akpm@linux-foundation.org, david@kernel.org,
peterx@redhat.com, ljs@kernel.org, imbrenda@linux.ibm.com,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
frankja@linux.ibm.com, "Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Muchun Song" <muchun.song@linux.dev>,
"Oscar Salvador" <osalvador@suse.de>,
"Jann Horn" <jannh@google.com>,
"Pedro Falcato" <pfalcato@suse.de>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v3 6/9] mm/mmu_notifier: add MMU_NOTIFIER_RANGE_PERM_UPGRADE
Date: Fri, 13 Nov 2026 14:25:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-212981@kernel.org> (raw)
In-Reply-To: <20261112142039.907090-8-clopez@suse.de>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm: change_protection() strips write bit for soft-dirty on
perm upgrade
--
commit 292879801a9c3725b053aaa1391bad7e3b1f0588
Author: Carlos López <clopez@suse.de>
mm/mmu_notifier: add MMU_NOTIFIER_RANGE_PERM_UPGRADE
This commit adds the MMU_NOTIFIER_RANGE_PERM_UPGRADE flag to indicate that a
range invalidation only upgrades access permissions, and sets it in
change_protection() for permission upgrades and userfaultfd write-protect
resolves.
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 70922e19c741d..ce3dd4b23c25b 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -582,8 +582,9 @@ static inline long change_pud_range(struct mmu_gather *tlb,
> continue;
>
> if (!range.start) {
> - mmu_notifier_range_init(&range,
> - MMU_NOTIFY_PROTECTION_VMA, 0,
> + mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_VMA,
> + mm_cp_is_perm_upgrade(cp_flags) ?
> + MMU_NOTIFIER_RANGE_PERM_UPGRADE : 0,
> vma->vm_mm, addr, end);
> mmu_notifier_invalidate_range_start(&range);
> }
[Severity: Medium]
Can change_protection() still downgrade writable entries to read-only when
MMU_NOTIFIER_RANGE_PERM_UPGRADE is set on a VMA with soft-dirty tracking
enabled?
When vma_soft_dirty_enabled(vma) is true, newprot lacks the write bit, so
pte_modify(), pmd_modify(), and pud_modify() clear it. When restoring
writability, set_write_prot_commit_flush_ptes() delegates to
maybe_change_pte_writable(), which returns false whenever
pte_needs_soft_dirty_wp() is true even if pte_write(oldpte) was set:
mm/mprotect.c:set_write_prot_commit_flush_ptes() {
if (pte_write(oldpte)) {
set_write = maybe_change_pte_writable(vma, ptent);
prot_commit_flush_ptes(vma, addr, ptep, oldpte, ptent, nr_ptes,
/* idx = */ 0, set_write, tlb);
return;
}
...
}
can_change_pmd_writable() and can_change_pud_writable() similarly reject
entries lacking the soft-dirty bit before checking pmd_write(oldpmd) or
pud_write(oldpud).
Writing 4 (CLEAR_REFS_SOFT_DIRTY) to /proc/pid/clear_refs enables soft-dirty
tracking on all VMAs while clear_refs_test_walk() skips VM_PFNMAP VMAs, and
clear_soft_dirty() skips pinned PTEs via pte_is_pinned() (which can be
writable without the soft-dirty bit after a read swap-in of an exclusive
anonymous page). A subsequent permission upgrade or userfaultfd resolve
then advertises MMU_NOTIFIER_RANGE_PERM_UPGRADE while write-protecting those
present entries, leaving secondary MMUs with stale writable mappings or
breaking CoW pin coherency.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112142039.907090-2-clopez@suse.de?part=6
next prev parent reply other threads:[~2026-11-13 14:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 14:20 [PATCH v3 0/9] KVM: don't zap secondary MMU on permission upgrade Carlos López
2026-11-12 14:20 ` [PATCH v3 1/9] mm: fix eager write-bit restore for write-notified shared mappings Carlos López
2026-11-12 14:20 ` [PATCH v3 2/9] riscv: mm: add pud_soft_dirty() Carlos López
2026-11-12 14:20 ` [PATCH v3 3/9] mm/huge_memory: honor MM_CP_TRY_CHANGE_WRITABLE in change_huge_pud() Carlos López
2026-11-12 14:20 ` [PATCH v3 4/9] mm: keep writable entries writable on protection changes Carlos López
2026-11-12 14:20 ` [PATCH v3 5/9] mm/mprotect: add MM_CP_PERM_UPGRADE Carlos López
2026-11-12 14:20 ` [PATCH v3 6/9] mm/mmu_notifier: add MMU_NOTIFIER_RANGE_PERM_UPGRADE Carlos López
2026-11-13 14:25 ` sashiko-bot [this message]
2026-11-12 14:20 ` [PATCH v3 7/9] KVM: pass the mmu_notifier event and flags to kvm_gfn_range Carlos López
2026-11-12 14:20 ` [PATCH v3 8/9] KVM: x86/mmu: don't zap secondary MMU on permission upgrade Carlos López
2026-11-12 14:20 ` [PATCH v3 9/9] KVM: s390: don't unmap the gmap " Carlos López
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=sashiko-outbox-212981@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=clopez@suse.de \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanjc@google.com \
--cc=surenb@google.com \
--cc=vbabka@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