Re: [PATCH v3 6/9] mm: add hw_pte_val for HW PTE storage
From: sashiko-bot@kernel.org
Date: 2026-09-22 17:22:33
Also in:
bpf, damon, dri-devel, intel-gfx, linux-perf-users
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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