Re: pud_bad vs pud_bad

[Ingo Molnar <mingo@elte.hu>]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
>> * Jeremy Fitzhardinge <jeremy@goop.org> 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.

So i'd go with the 32-bit version. (unless there are some sign-extension 
complications i'm missing - but i think we got rid of those already.)

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>