Messages in this thread | | | Date | Thu, 07 May 2015 12:40:24 -0700 | From | Dave Hansen <> | Subject | Re: [PATCH 00/12] [RFC] x86: Memory Protection Keys |
| |
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.
| |