On Thu, Sep 18, 2014 at 12:40:29AM +0000, Ren, Qiaowei wrote:
> > Would it be prudent to use an error code other than EINVAL for the
> > "hardware doesn't support it" case?
> >
> Seems like no specific error code for this case.
ENXIO would probably be OK. It's not too important as long as it's
documented.
>
> >> @@ -2011,6 +2017,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned
> > long, arg2, unsigned long, arg3,
> >> me->mm->def_flags &= ~VM_NOHUGEPAGE;
> >> up_write(&me->mm->mmap_sem);
> >> break;
> >> + case PR_MPX_REGISTER:
> >> + error = MPX_REGISTER(me);
> >> + break;
> >> + case PR_MPX_UNREGISTER:
> >> + error = MPX_UNREGISTER(me);
> >> + break;
> >
> > If you pass me->mm from prctl, that makes it clear that it's
> > per-process not per-thread, just like PR_SET_DUMPABLE / PR_GET_DUMPABLE.
> >
> > This code should also enforce nulls in arg2 / arg3 / arg4,/ arg5 if
> > it's not using them, otherwise you'll be sunk if you ever want to use them
> > later.
> >
> > It seems like it only makes sense for all threads using the mm to have
> > the same bounds directory set. If the interface was changed to
> > directly pass the address, then could the kernel take care of setting
> > it for *all* of the threads in the process? This seems like something
> > that would be easier for the kernel to do than userspace.
> >
> If the interface was changed to this, it will be possible for insane
> application to pass error bounds directory address to kernel. We still
> have to call fpu_xsave() to check this.
I was actually thinking that the kernel would take care of the xsave /
xrstor (for current), updating tsk->thread.fpu.state (for non-running
threads) and sending an IPI for threads running on other CPUs.
Of course userspace can always then manually change the bounds directory
address itself, but then it's quite clear that they're doing something
unsupported. Just an idea, anyway.
- Kevin
--
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/
