Re: [PATCH v4 01/14] mm: decouple protnone helpers from CONFIG_NUMA_BALANCING

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional selection of ARCH_HAS_PTE_PROTNONE on LoongArch causes boot-time warnings/panics in debug_vm_pgtable on 32-bit configurations.
--

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

mm: decouple protnone helpers from CONFIG_NUMA_BALANCING

Introduce CONFIG_ARCH_HAS_PTE_PROTNONE to decouple the protnone PTE
infrastructure from CONFIG_NUMA_BALANCING.

> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index 606597da46b8d..77e9a9a30483f 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -67,6 +67,7 @@ config LOONGARCH
>  	select ARCH_SUPPORTS_LTO_CLANG
>  	select ARCH_SUPPORTS_LTO_CLANG_THIN
>  	select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
> +	select ARCH_HAS_PTE_PROTNONE

[Severity: High]
Does unconditionally selecting ARCH_HAS_PTE_PROTNONE introduce a regression
by causing a boot-time warning in debug_vm_pgtable on 32-bit LoongArch
configurations?

On 32-bit LoongArch (CONFIG_32BIT), _PAGE_PROTNONE is defined as 0. This
makes pte_protnone() always return 0. During boot, pte_protnone_tests() in
mm/debug_vm_pgtable.c executes WARN_ON(!pte_protnone(pte)), leading to a
kernel panic on systems with panic_on_warn.

Prior to this patch, these tests skipped 32-bit LoongArch because they were
gated by CONFIG_NUMA_BALANCING.

Will this also cause a regression for generic features depending on
ARCH_HAS_PTE_PROTNONE (like userfaultfd RWP), causing them to fail silently
on 32-bit LoongArch since they expect pte_protnone() to accurately identify
PROT_NONE PTEs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525113737.1942478-1-kas@kernel.org?part=1