Linux s390 Architecture development
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-11-13 14:25 UTC|newest]

Thread overview: 28+ 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-13 14:25   ` sashiko-bot
2026-11-13 20:47   ` Lorenzo Stoakes (ARM)
2026-11-12 14:20 ` [PATCH v3 2/9] riscv: mm: add pud_soft_dirty() Carlos López
2026-11-13 14:25   ` sashiko-bot
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-13 14:25   ` sashiko-bot
2026-11-13 18:58   ` David Hildenbrand (Arm)
2026-11-13 20:48   ` Lorenzo Stoakes (ARM)
2026-11-12 14:20 ` [PATCH v3 4/9] mm: keep writable entries writable on protection changes Carlos López
2026-11-13 14:25   ` sashiko-bot
2026-11-13 18:56   ` David Hildenbrand (Arm)
2026-11-12 14:20 ` [PATCH v3 5/9] mm/mprotect: add MM_CP_PERM_UPGRADE Carlos López
2026-11-13 14:25   ` sashiko-bot
2026-11-13 18:51   ` David Hildenbrand (Arm)
2026-11-13 20:37   ` Lorenzo Stoakes (ARM)
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-13 14:25   ` sashiko-bot
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-13 14:25   ` sashiko-bot
2026-11-12 14:20 ` [PATCH v3 9/9] KVM: s390: don't unmap the gmap " Carlos López
2026-11-13 14:26   ` sashiko-bot
2026-11-13 19:00 ` [PATCH v3 0/9] KVM: don't zap secondary MMU " David Hildenbrand (Arm)
2026-11-13 20:32   ` Lorenzo Stoakes (ARM)
2026-11-13 20:59 ` Lorenzo Stoakes (ARM)

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