On Tue, 14 Jul 2026 13:55:18 +0200 "Arnd Bergmann" <[email protected]> wrote:
> 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 x86-32 the makefiles request 64bit structures be returned in registers (at the same place regparm=3 is set - probably added at the same time between 2.4 and 2.6). Note that arm32 can will return a 32bit struct in a register and arm64 will return a 128bit struct in two registers. The only problem is returning a 64bit struct in 32bit mode. I'm sure this code is arm64 only. David > > 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 >
