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

On Fri, Jul 17, 2026 at 08:16:55AM +0200, Arnd Bergmann wrote:
> 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.

Thanks. Even my simple tests with GCC versions 8.5.0 through 16.1.0 in [0],
did not spill to the stack. So keeping David's original implementation
seems reasonable.

Link: [0] https://www.kernel.org/pub/tools/crosstool/

-- 
Sincerely,
Yeoreum Yun