On Tue, Jul 14, 2026, at 12:26, Pedro Falcato wrote: > On Mon, Jul 13, 2026 at 02:55:41PM +0100, Yeoreum Yun wrote: >> From: "David Hildenbrand (Arm)" <[email protected]> >> >> We don't want pgd_t to be an array, as it prohibits returning it from a >> function, like pgdp_get(). >> >> So let's just use an u64, and extract the right 32bit value in >> pgd_val(). >> >> Leave the STRICT_MM_TYPECHECKS case alone for now. > > I have to ask: is there a good reason for the STRICT_MM_TYPECHECKS ifdef? > > I see the compiler has an awkward time returning a u64 struct (see > https://godbolt.org/z/qejbv6j9a), but if this doesn't work maybe we should > get rid of the STRICT_MM_TYPECHECKS stuff? I seriously doubt anyone is > purposefully toggling it on for testing from time to time.
As far as I can tell, the #ifdef was originally in i386 and got copied to all other architectures at the time, but was removed in linux-2.3.23 from the original copy when CONFIG_X86_PAE was introduced. For some reason, only sparc32 and arm32 still use the non-strict version, with arm having changed from the struct version in 2002: https://github.com/tbodt/linux-history/commit/5a8202f0259a https://archive.armlinux.org.uk/lurker/message/20020306.213958.cd486eeb.en.html > If STRICT_MM_TYPEDEFS's worse codegen doesn't matter then maybe we should > permanently toggle it on. This would definitely need good testing. It's possible that it's not that bad on modern EABI builds (i.e. everyone these days) as well as modern compilers, as OABI definitely had bigger problems with 64-bit arguments. >> +static inline pmdval_t pgd_val(pgd_t pgd) >> +{ >> + return (*(pmdval_t (*)[2])&pgd)[0]; > > 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. Arnd
