Re: pud_bad vs pud_bad

[Ingo Molnar]

* Hugh Dickins <hugh@xxxxxxxxxxx> wrote:

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

yes, indeed you are right - the 64-bit test does not allow the KERNPG_TABLE 
bits to go zero.

Those are the present, rw, accessed and dirty bits. Do they really matter 
that much? If a toplevel entry goes !present or readonly, we notice that 
_fast_, without any checks. If it goes !access or !dirty - does that matter?

These checks are done all the time, and even a single instruction can count. 
The bits that are checked are enough to notice random memory corruption.

( albeit these days with large RAM sizes pagetable corruption is quite rare 
  and only happens if it's specifically corrupting the pagetable - and then 
  it's not just a single bit. Most of the memory corruption goes into the 
  pagecache. )

	Ingo
--
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/