Messages in this thread | | | Date | Tue, 28 Jan 2014 10:26:37 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH v3 0/4] Intel MPX support |
| |
On 01/27/2014 11:01 PM, Ren Qiaowei wrote: > > Yes. Though all non-MPX threads are slowed down, the whole process > benefit from MPX. > > Anyway, HPA suggest these syscalls, which use MMU notifier, should be > not needed, we can do what they do in userspace runtime. What do you > think about it? I guess that I should remove the third patch which adds > new prctl() syscalls in next version of this patchset. >
The syscalls is one thing, managing the bounds map in kernel space is another.
We could manage the bounds map entirely in user space in a signal handler, but that has both ABI issues (#BR currently turns into SIGSEGV which is commonly hooked by applications; we could switch to a different signal but there aren't many unclaimed ones) and performance issues.
I would think it would be extremely unusual for an application to have some MPX and some non-MPX threads, since they would share the same address space and the non-MPX threads would mess up the bounds.
-hpa
| |