From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
kirill.shutemov@linux.intel.com
Subject: Re: [RFC][PATCH 3/7] x86, mpx: extend MPX prctl() to pass in size of bounds directory
Date: Sun, 12 Feb 2017 20:15:20 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1702122006230.3734@nanos> (raw)
In-Reply-To: <20170201232412.BB0806BA@viggo.jf.intel.com>
On Wed, 1 Feb 2017, Dave Hansen wrote:
> FIXME: we also need to ensure that we check the current state of the
> larger address space opt-in. If we've opted in to larger address spaces
> we can not allow a small bounds directory to be used. Also, if we've
> not opted in, we can not allow the larger bounds directory to be used.
> This can be fixed once the in-kernel API for opting in/out is settled.
Ok.
> /* Register/unregister a process' MPX related resource */
> -#define MPX_ENABLE_MANAGEMENT() mpx_enable_management()
> +#define MPX_ENABLE_MANAGEMENT(bd_size) mpx_enable_management(bd_size)
> #define MPX_DISABLE_MANAGEMENT() mpx_disable_management()
Please add another tab before mpx_disable so both are aligned.
> -int mpx_enable_management(void)
> +int mpx_set_mm_bd_size(unsigned long bd_size)
static ?
> +{
> + struct mm_struct *mm = current->mm;
> +
> + switch ((unsigned long long)bd_size) {
> + case 0:
> + /* Legacy call to prctl(): */
> + mm->context.mpx_bd_shift = 0;
> + return 0;
> + case MPX_BD_SIZE_BYTES_32:
> + /* 32-bit, legacy-sized bounds directory: */
> + if (is_64bit_mm(mm))
> + return -EINVAL;
> + mm->context.mpx_bd_shift = 0;
> + return 0;
> + case MPX_BD_BASE_SIZE_BYTES_64:
> + /* 64-bit, legacy-sized bounds directory: */
> + if (!is_64bit_mm(mm)
> + // FIXME && ! opted-in to larger address space
Hmm. Confused. This is where we enable MPX and decode the requested address
space. How can an already opt in happen?
If that's a enable call for an already enabled thing, then we should catch
that at the call site, I think.
> + case MPX_BD_BASE_SIZE_BYTES_64 << MPX_LARGE_BOUNDS_DIR_SHIFT:
> + /*
> + * Non-legacy call, with larger directory.
> + * Note that there is no 32-bit equivalent for
> + * this case since its address space does not
> + * change sizes.
> + */
> + if (!is_64bit_mm(mm))
> + return -EINVAL;
> + /*
> + * Do not let this be enabled unles we are on
> + * 5-level hardware *and* have that feature
> + * enabled. FIXME: need runtime check
Runtime check? Isn't the feature bit enough?
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-02-12 19:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 23:24 [RFC][PATCH 0/7] x86, mpx: Support larger address space (MAWA) (v2) Dave Hansen
2017-02-01 23:24 ` [RFC][PATCH 1/7] x86, mpx: introduce per-mm MPX table size tracking Dave Hansen
2017-02-01 23:24 ` [RFC][PATCH 2/7] x86, mpx: update MPX to grok larger bounds tables Dave Hansen
2017-02-12 19:05 ` Thomas Gleixner
2017-02-01 23:24 ` [RFC][PATCH 3/7] x86, mpx: extend MPX prctl() to pass in size of bounds directory Dave Hansen
2017-02-12 19:15 ` Thomas Gleixner [this message]
2017-02-01 23:24 ` [RFC][PATCH 4/7] x86, mpx: context-switch new MPX address size MSR Dave Hansen
2017-02-12 19:37 ` Thomas Gleixner
2017-02-01 23:24 ` [RFC][PATCH 5/7] x86, mpx: shrink per-mm MPX data Dave Hansen
2017-02-12 22:44 ` Thomas Gleixner
2017-02-01 23:24 ` [RFC][PATCH 6/7] x86, mpx, selftests: Use prctl header instead of magic numbers Dave Hansen
2017-02-01 23:24 ` [RFC][PATCH 7/7] x86, mpx: update MPX selftest to test larger bounds dir Dave Hansen
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=alpine.DEB.2.20.1702122006230.3734@nanos \
--to=tglx@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox