lkml.org 
[lkml]   [2009]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: pud_bad vs pud_bad

* 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


\
 
 \ /
  Last update: 2009-02-05 20:13    [W:0.174 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site