[RFC PATCH 02/34] ARM: mm: make 2-level pgd_t a scalar

[Arnd Bergmann]

On Thu, Jul 16, 2026, at 21:04, Yeoreum Yun wrote:
>>
>> > Ugh. This isn't correct C code. It only works because the kernel passes
>> > -fno-strict-aliasing.
>> 
>> I think the bigger problem is the code dereferencing the pgd
>> pointer in the first place: Since the pgd pair is written in
>> 32-bit units in __pmd_populate(), anything reading it would
>> technically have to operate on both entries.
>> 
>> As the kernel relies on -fno-strict-aliasing, the type mismatch
>> is less of a problem than actually doing the potentially wrong
>> thing.
>> 
>> As far as I can tell, we are however saved by pgd_val()
>> only ever being used for debug prints, where printing
>> the first entry is likely all that is needed to analyse
>> the real bug.
>> 
>> > I would recommend either forcing a struct here, or
>> > using a u64 with bitmasks/shifts.
>> 
>> That would require extra complexity for the big-endian
>> case though.
>
> Agree. And since the users of pgd_val() mostly uses with
> pmd_pfn(), pmd_page() and etc. I think it doesn't matter to return
> lower pmdval_t or higher one.
>
> Therefore, without considering endianess, it's enough with downcast
> like:
>
>    #define pgd_val(x)      ((pmdval_t)x)
>
> Could we apply this in next version?

I would just leave the original version here, at least it
keeps the current behavior for something that is easy to
get wrong. Taking the second entry on big-endian sounds
counterintuitive, especially when you have a hugetlb
mapping where the two don't just point to the same page.

      Arnd