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

[...]

> > 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?

-- 
Sincerely,
Yeoreum Yun