Messages in this thread | | | Date | Wed, 02 Apr 2008 07:01:33 -0700 | From | Arjan van de Ven <> | 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: >> >>> But what mappings are there, immediately after alloc_page(), that >>> set_memory_np won't catch? >> >> For example on x86 64bit, the kernel text is mapped (to allow >> relocatable) in another >> space as well.. and to allow 2Mb tlbs for this, that second mapping is >> bigger than it strictly needs to be. >> So your alloc_page() could get a page from the free pool that comes >> from the pages that have a second mapping >> due to this rounding. >> (and more fun, since it's close to frequently accessed memory, the hw >> prefetchers may actually just decide to pull >> such pages into the cache preemptively) >> >> >>> Drivers relying on set_memory_uc touching all mappings the driver >>> hasn't set up itself must then have the same problem and needs to be >>> fixed; referring in particular to agpgart for which driver the old >>> CPA functionality was once created, IIRC. >> >> "uc" is different than "np"; for "uc" the implementation, if your cpu >> needs this, will fix >> up the shadow text mappings already today. >> >> for "present" this doesn't make sense, since no cpu needs this. > If this is the checkalias() thingy in x86/pageattr.c, it looks like it > doesn't handle np different from the uc case. It does obviously skip NX > bit manipulations, though. > > Anyway, a more direct question: If we were to fix whatever's missing for > the code to fixup the x86-64 shadow text mapping, would you be opposing > this way
I do really oppose set_memory_np/p to work on anything but the mapping it is handled. that _uc and co touch other mappings is a cpu specific property and an implementation detail to the API. If/When CPUs exist that don't have issues with aliases, those CPUs will not change the other mappings.
> to fix the long standing uc/wc aliasing issue, provided we
I'm not opposed to a real fix. I am opposed to a bad hack.
> don't hit any other problems, like clflush() refusing to run on an NP page?
yes clflush doesn't work on not present pages ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |