Re: [PATCH v3 6/9] mm: add hw_pte_val for HW PTE storage

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mm: hw_pte_val() yields an rvalue on x86, breaking its lvalue API promise
--

commit 06b6d3a311b681bd0fa817067b39f468d3e5ca27
Author: Muhammad Usama Anjum <usama.anjum@arm.com>

mm: add hw_pte_val for HW PTE storage

This commit introduces the hw_pte_val() macro to expose the underlying
pte_val() as an lvalue for atomic PTE updates. It provides definitions
for both when hw_pte_t is distinct and when it aliases pte_t.

> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
> index d6c5a7548550b..ee4eace5c3e1c 100644
> --- a/include/linux/pgtable_types.h
> +++ b/include/linux/pgtable_types.h
> @@ -9,9 +9,13 @@
>  #ifdef CONFIG_ARCH_HAS_HW_PTE_T
>  typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
>  #define __pte_from_hw(pte)	((pte).__pte)
> +
> +#define hw_pte_val(x)  pte_val((x).__pte)

[Severity: Low]
Will this macro actually yield an lvalue on all architectures?

While pte_val(x) is a macro yielding an lvalue on some architectures like
arm64, it is implemented as a static inline function on others such as x86,
s390, and MIPS (e.g., native_pte_val(x)).

Since a function return is an rvalue in C, attempts to use hw_pte_val() as
an lvalue (such as taking its address via &hw_pte_val(pte) for cmpxchg())
will trigger a compiler error like "lvalue required as left operand" on
those architectures.

>  #else
>  #define hw_pte_t pte_t
>  #define __pte_from_hw(pte)	(pte)
> +
> +#define hw_pte_val(x)  pte_val(x)

[Severity: Low]
Does this fallback definition suffer from the same issue?

Since it relies directly on pte_val(x), it inherits the rvalue limitation
on architectures where pte_val() is an inline function, breaking the intended
lvalue abstraction.

>  #endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-pte0-v3-0-5670b8cb9059@arm.com?part=6