On 05/07/2015 12:26 PM, Ingo Molnar wrote: > The Valgrind usecase looks somewhat legit, albeit not necessarily for > multithreaded apps: there you generally really want protection changes > to be globally visible, such as publishing the effects of free() or > malloc().
I guess we could theoretically have an IPC of some kind that voluntarily broadcasts changes so that we can be guaranteed that other threads see it. > Also, will apps/libraries bother if it's not a standard API and if it > only runs on very fresh CPUs? It's always a problem with new CPU features. I've thought a bit about trying to "emulate" the feature on older CPUs using good ol' mprotect() so that we could have an API that folks can use _today_, but that would get magically fast on future CPUs. But, the problem with that is the thread-local aspect. mprotect() is fundamentally process-wide and protection keys right are fundamentally thread-local. Those things are going to be hard to reconcile unless we do something slightly extreme like having per-thread page tables. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
