Re: pud_bad vs pud_bad

[Hugh Dickins]

On Thu, 5 Feb 2009, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> > Ingo Molnar wrote:
> >> * Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> >>   
> >>> I'm looking at unifying the 32 and 64-bit versions of pud_bad.
> >>>
> >>> 32-bits defines it as:
> >>>
> >>> static inline int pud_bad(pud_t pud)
> >>> {
> >>> 	return (pud_val(pud) & ~(PTE_PFN_MASK | _KERNPG_TABLE | _PAGE_USER)) != 0;
> >>> }
> >>>
> >>> and 64 as:
> >>>
> >>> static inline int pud_bad(pud_t pud)
> >>> {
> >>> 	return (pud_val(pud) & ~(PTE_PFN_MASK | _PAGE_USER)) != _KERNPG_TABLE;
> >>> }
> >>>
> >>>
> >>> I'm inclined to go with the 64-bit version, but I'm wondering if 
> >>> there's something subtle I'm missing here.
> >>>     
> >>
> >> Why go with the 64-bit version? The 32-bit check looks more compact and 
> >> should result in smaller code.
> >>   
> >
> > Well, its stricter.  But I don't really understand what condition its  
> > actually testing for.
> 
> Well it tests: "beyond the bits covered by PTE_PFN|_PAGE_USER, the rest 
> must only be _KERNPG_TABLE".
> 
> The _KERNPG_TABLE bits are disjunct from PTE_PFN|_PAGE_USER bits, so this 
> makes sense.
> 
> But the 32-bit check does the exact same thing but via a single binary 
> operation: it checks whether any bits outside of those bits are zero -
> just via a simpler test that compiles to more compact code.

Simpler and more compact, but not as strict: in particular, a value of
0 or 1 is identified as bad by that 64-bit test, but not by the 32-bit.

I most definitely prefer the stricter 64-bit version.  I thought we'd
gone around this all before, but maybe that was for pmd_bad(): there
too one variant was weaker than the other and we went for the stronger.

However... I forget how the folding works out.  The pgd in the 32-bit
PAE case used to have just the pfn and the present bit set in that
little array of four entries: if pud_bad() ends up getting applied
to that, I guess it will blow up.

If so, my preferred answer would actually be to make those 4 entries
look more like real ptes; but you may think I'm being a bit silly.

Not quite sure why wli is Cc'ed but I've fixed his address:
it's good to see you back, Bill.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/