[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <478D1B6F.8020003@goop.org>
Date: Tue, 15 Jan 2008 12:45:35 -0800
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Venki Pallipadi <venkatesh.pallipadi@...el.com>
CC: Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: Folding _PAGE_PWT into _PAGE_PCD (was Re: unify pagetable accessors
patch causes double fault II)
Venki Pallipadi wrote:
> On Tue, Jan 15, 2008 at 09:16:50AM -0800, Jeremy Fitzhardinge wrote:
>
>> Ingo Molnar wrote:
>>
>>> -#define _PAGE_PRESENT (_AC(1, UL)<<_PAGE_BIT_PRESENT)
>>> -#define _PAGE_RW (_AC(1, UL)<<_PAGE_BIT_RW)
>>> -#define _PAGE_USER (_AC(1, UL)<<_PAGE_BIT_USER)
>>> -#define _PAGE_PWT (_AC(1, UL)<<_PAGE_BIT_PWT)
>>> -#define _PAGE_PCD ((_AC(1, UL)<<_PAGE_BIT_PCD) | _PAGE_PWT)
>>>
>>>
>> BTW, I just noticed that _PAGE_PWT has been folded into _PAGE_PCD. This
>> seems like a really bad idea to me, since it breaks the rule that
>> _PAGE_X == 1 << _PAGE_BIT_X. I can't think of a specific place where
>> this would cause problems, but this kind of non-uniformity always ends
>> up biting someone in the arse.
>>
>> I think having a specific _PAGE_NOCACHE which combines these bits is a
>> better approach.
>>
>> J
>>
>
> How about the patch below. It defines new _PAGE_UC. One concern is drivers
> continuing to use _PAGE_PCD and getting wrong attributes. May be we need to
> rename _PAGE_PCD to catch those errors as well?
>
Sure, looks fine. I would have said that _NOCACHE matches current usage
better, but if it makes more sense to have _UC and _WC then that's fine
with me.
I guess renaming _PAGE_BIT_PCD to _PAGE_BIT__PCD and the corresponding
_PAGE__PCD might be reasonable if you think there's a chance of new
misusers appearing (I guess something like out of tree DRI/proprietary
patches are a source of that).
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists