From: Dave Hansen <dave.hansen@linux.intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org
Subject: Re: [GIT pull] x86 mpx support for 3.19
Date: Wed, 10 Dec 2014 18:30:00 -0800 [thread overview]
Message-ID: <548901A8.6020805@linux.intel.com> (raw)
In-Reply-To: <877fxzexuz.fsf@x220.int.ebiederm.org>
On 12/10/2014 06:14 PM, Eric W. Biederman wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>> please pull the latest x86-mpx-for-linus git tree from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mpx-for-linus
>>
>> This enables support for x86 MPX:
>>
>> MPX is a new debug feature for bound checking in user space. It
>> requires kernel support to handle the bound tables and decode the
>> bound violating instruction in the trap handler.
>
> I some really dumb questions.
>
> Given that mpx is both architecture and cpu specific why use prctl?
> I would think arch_prctl would be a much more appropriate place to
> expose this logic.
I actually never considered arch_prctl(). It doesn't seem a bad fit for
any reason, just that I never thought of it and no one suggested it up
to this point.
Is there any *real* advantage to arch_prctl()? We have some gcc code
that's going to be using these prctls and if we need to change the
interface, we've got to get that code changed too... fast.
> Why don't you have a call to let an application query to see if mpx
> management is enabled? I am trying to imagine how checkpoint/restart is
> going to be supported for mpx applications. If I can't even query if
> mpx is enabled I don't have a clue how we could save this state and
> duplicate it in another process on another machine.
You probably need to actually save off the contents of mm->bd_addr
itself. I guess you can do it along with all the other internals of the
mm that get saved off currently.
prev parent reply other threads:[~2014-12-11 2:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 14:08 [GIT pull] x86 mpx support for 3.19 Thomas Gleixner
2014-12-10 19:05 ` Linus Torvalds
2014-12-10 19:41 ` Dave Hansen
2014-12-10 19:49 ` Linus Torvalds
2014-12-10 20:39 ` Dave Hansen
2014-12-10 20:49 ` Linus Torvalds
2014-12-12 16:40 ` H. Peter Anvin
2014-12-11 6:19 ` Ingo Molnar
2014-12-11 22:02 ` Dave Hansen
2014-12-12 8:31 ` Ingo Molnar
2014-12-12 12:30 ` Pavel Machek
2014-12-12 15:47 ` Dave Hansen
2014-12-12 17:21 ` Pavel Machek
2014-12-10 19:49 ` Dave Hansen
2014-12-11 2:14 ` Eric W. Biederman
2014-12-11 2:30 ` Dave Hansen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=548901A8.6020805@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.