From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org
Cc: Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/2] arm64/mm: Move __check_safe_pte_update()
Date: Mon, 7 Sep 2026 17:48:18 +0200 [thread overview]
Message-ID: <a70e45cc-dbf7-40da-81e8-ee6055f2692f@kernel.org> (raw)
In-Reply-To: <20260901065454.1906343-2-anshuman.khandual@arm.com>
On 9/1/26 08:54, Anshuman Khandual wrote:
> The page table entry print helpers and related macros which are defined in
> <linux/pgtable.h> will not be accessible in platform <asm/pgtable.h> which
> is basically caused by cycling dependency.
>
> Move __check_safe_pte_update() inside arch/arm64/mm/mmu.c as a preparation
> for subsequent usage of the afore mentioned generic MM helpers.
>
> This does not cause any functional change.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> Should __check_safe_pte_update() be wrapped in #ifdef CONFIG_DEBUG_VM
> along with dropping off current IS_ENABLED() test. That would ensure
> the function never gets called when CONFIG_DEBUG_VM is disabled. That
> will preserve current behaviour as the inline function gets dropped
> when CONFIG_DEBUG_VM remains disabled.
>
> arch/arm64/include/asm/pgtable.h | 47 +-------------------------------
> arch/arm64/mm/mmu.c | 45 ++++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+), 46 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e89ec5f4787b..61fbfab3e06e 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -387,52 +387,7 @@ static inline pte_t __ptep_get(pte_t *ptep)
> extern void __sync_icache_dcache(pte_t pteval);
> bool pgattr_change_is_safe(pteval_t old, pteval_t new);
>
> -/*
> - * PTE bits configuration in the presence of hardware Dirty Bit Management
> - * (PTE_WRITE == PTE_DBM):
> - *
> - * Dirty Writable | PTE_RDONLY PTE_WRITE PTE_DIRTY (sw)
> - * 0 0 | 1 0 0
> - * 0 1 | 1 1 0
> - * 1 0 | 1 0 1
> - * 1 1 | 0 1 x
> - *
> - * When hardware DBM is not present, the software PTE_DIRTY bit is updated via
> - * the page fault mechanism. Checking the dirty status of a pte becomes:
> - *
> - * PTE_DIRTY || (PTE_WRITE && !PTE_RDONLY)
> - */
> -
> -static inline void __check_safe_pte_update(struct mm_struct *mm, pte_t *ptep,
> - pte_t pte)
> -{
> - pte_t old_pte;
> -
> - if (!IS_ENABLED(CONFIG_DEBUG_VM))
> - return;
> -
> - old_pte = __ptep_get(ptep);
> -
> - if (!pte_valid(old_pte) || !pte_valid(pte))
> - return;
> - if (mm != current->active_mm && atomic_read(&mm->mm_users) <= 1)
> - return;
> -
> - /*
> - * Check for potential race with hardware updates of the pte
> - * (__ptep_set_access_flags safely changes valid ptes without going
> - * through an invalid entry).
> - */
> - VM_WARN_ONCE(!pte_young(pte),
> - "%s: racy access flag clearing: 0x%016llx -> 0x%016llx",
> - __func__, pte_val(old_pte), pte_val(pte));
> - VM_WARN_ONCE(pte_write(old_pte) && !pte_dirty(pte),
> - "%s: racy dirty state clearing: 0x%016llx -> 0x%016llx",
> - __func__, pte_val(old_pte), pte_val(pte));
> - VM_WARN_ONCE(!pgattr_change_is_safe(pte_val(old_pte), pte_val(pte)),
> - "%s: unsafe attribute change: 0x%016llx -> 0x%016llx",
> - __func__, pte_val(old_pte), pte_val(pte));
> -}
> +void __check_safe_pte_update(struct mm_struct *mm, pte_t *ptep, pte_t pte);
>
That implies that any __set_ptes_anysz() will invoke another function call that
will not be optimized out.
You should likely keep most of __check_safe_pte_update() in the header as an
inline function (or at least the CONFIG_DEBUG_VM check), and only move the "slow
path" code.
Alternatively, make the whole thing #ifdef CONFIG_DEBUG_VM and provide an empty
inline helper for !CONFIG_DEBUG_VM.
That's probably the cleanest, because performance with CONFIG_DEBUG_VM is not
really relevant.
--
Cheers,
David
next prev parent reply other threads:[~2026-09-07 15:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 6:54 [PATCH 0/2] arm64/mm: Standardize printing for pgtable entries Anshuman Khandual
2026-09-01 6:54 ` [PATCH 1/2] arm64/mm: Move __check_safe_pte_update() Anshuman Khandual
2026-09-07 15:48 ` David Hildenbrand (Arm) [this message]
2026-09-08 4:27 ` Anshuman Khandual
2026-09-01 6:54 ` [PATCH 2/2] arm64/mm: Standardize printing for pgtable entries Anshuman Khandual
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=a70e45cc-dbf7-40da-81e8-ee6055f2692f@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=rppt@kernel.org \
--cc=will@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
all inboxes | Powered by JetHome®