On 2014-09-15, One Thousand Gnomes wrote:
>> The base of the bounds directory is set into mm_struct during
>> PR_MPX_REGISTER command execution. This member can be used to check
>> whether one application is mpx enabled.
>
> Not really because by the time you ask the question another thread
> might have decided to unregister it.
>
>
>> +int mpx_register(struct task_struct *tsk) {
>> + struct mm_struct *mm = tsk->mm;
>> +
>> + if (!cpu_has_mpx)
>> + return -EINVAL;
>> +
>> + /*
>> + * runtime in the userspace will be responsible for allocation of
>> + * the bounds directory. Then, it will save the base of the bounds
>> + * directory into XSAVE/XRSTOR Save Area and enable MPX through
>> + * XRSTOR instruction.
>> + *
>> + * fpu_xsave() is expected to be very expensive. In order to do
>> + * performance optimization, here we get the base of the bounds
>> + * directory and then save it into mm_struct to be used in future.
>> + */
>> + mm->bd_addr = task_get_bounds_dir(tsk);
>> + if (!mm->bd_addr)
>> + return -EINVAL;
>
> What stops two threads calling this in parallel ?
>> +
>> + return 0;
>> +}
>> +
>> +int mpx_unregister(struct task_struct *tsk) {
>> + struct mm_struct *mm = current->mm;
>> +
>> + if (!cpu_has_mpx)
>> + return -EINVAL;
>> +
>> + mm->bd_addr = NULL;
>
> or indeed calling this in parallel
>
> What are the semantics across execve() ?
>
This will not impact on the semantics of execve(). One runtime library for MPX will be provided (or merged into Glibc), and when the application starts, this runtime will be called to initialize MPX runtime environment, including calling prctl() to notify the kernel to start managing the bounds directories. You can see the discussion about exec(): https://lkml.org/lkml/2014/1/26/199
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. That is to say, it looks like be unusual for one of these threads to call prctl() to enable or disable MPX. I guess we need to add some rules into documentation.
Thanks,
Qiaowei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href