![]() | |||||||||||||
Messages in this thread |
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 to fix the long standing uc/wc aliasing issue, provided we don't hit any other problems, like clflush() refusing to run on an NP page? /Thomas -- 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/ | ||||||||||||
| Last update: 2008-04-02 09:03 [from the cache] ©2003-2008 | |||||||||||||