[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47F2B788.1030101@linux.intel.com>
Date: Tue, 01 Apr 2008 15:30:32 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Thomas Hellström <thomas@...gstengraphics.com>
CC: Andi Kleen <andi@...stfloor.org>, Dave Airlie <airlied@...hat.com>,
linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH] x86: create array based interface to change page attribute
Thomas Hellström wrote:
> Arjan van de Ven wrote:
>> Thomas Hellström wrote:
>>> Given this problem, the previously mentioned use-case, and the fact
>>> that we mostly really use user-space mappings,
>>> Is there a possibility we could add the following functions to Dave's
>>> patch (provided they would work as intended, of course, namely
>>> invalidate / bring back the kernel mapping).
>>
>> sadly there are multiple mappings, both in theory and practice.
>> Especially the _np / _p functions specifically work on only the
>> mapping you specify.
>>
>> For this to work we would need to somehow make a "mark all mappings
>> NP, but please only do the kernel ones" kind of thing.
>> The semantics of that are... lets say messy at best.
> Hmm, I'm not sure I follow you here. Are you saying that it's illegal to
> have an NP mapping of a page (which, If I understand it correctly, means
> no mapping at all) at the same time as you have a, say user-space WC
> mapping pointing to the same physical page?
no.
What I'm saying is that even if you make one mapping NP, it's hard to know you got all of them,
even just the kernel one.
>
> I was under the impression that calling CPA on the kernel mapping of
> that page would do the rest?
this is not a correct assumption in general, especially not for things like
"present".
If a page is mapped 3 times in the kernel, and you set one to "np", the others
WILL stay mapped.
(and CPA itself no longer exists period ;)
--
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