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 <[email protected]> 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/[email protected]?part=6
