On 01/27/2014 01:54 PM, Andy Lutomirski wrote:
> On 01/26/2014 06:10 PM, H. Peter Anvin wrote:
>> On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
>>>
>>> Peter, you mean we should remove these two call and do what they do in
>>> user-space, right?
>>>
>>
>> Unless we think there is a benefit to the
On 01/26/2014 06:10 PM, H. Peter Anvin wrote:
> On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
>>
>> Peter, you mean we should remove these two call and do what they do in
>> user-space, right?
>>
>
> Unless we think there is a benefit to the kernel to have a on/off switch
> for the #BR exception (if
On 01/26/2014 01:08 AM, Qiaowei Ren wrote:
> This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
> commands on the x86 platform. These commands can be used to
> init and release MPX related resource.
>
> A MMU notifier will be registered during PR_MPX_INIT
> command execution. So the bound
On 01/26/2014 01:08 AM, Qiaowei Ren wrote:
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.
A MMU notifier will be registered during PR_MPX_INIT
command execution. So the bound
On 01/26/2014 06:10 PM, H. Peter Anvin wrote:
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
Peter, you mean we should remove these two call and do what they do in
user-space, right?
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled,
On 01/27/2014 01:54 PM, Andy Lutomirski wrote:
On 01/26/2014 06:10 PM, H. Peter Anvin wrote:
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
Peter, you mean we should remove these two call and do what they do in
user-space, right?
Unless we think there is a benefit to the kernel to have a
On 01/27/2014 10:10 AM, H. Peter Anvin wrote:
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
Peter, you mean we should remove these two call and do what they do in
user-space, right?
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled, all
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
>
> Peter, you mean we should remove these two call and do what they do in
> user-space, right?
>
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled, all #BR exceptions are signals,
regardless of
On 01/26/2014 11:14 PM, Ingo Molnar wrote:
* Ren, Qiaowei wrote:
The size of one bound table is 4M bytes for 64bit, and 16K bytes for
32bit. It can not be accessed by user-space, and it will be accessed
automatically by hardware.
So, here's the bound-table allocation AFAICS:
+static bool
On 01/27/2014 09:50 AM, H. Peter Anvin wrote:
On 01/26/2014 12:39 AM, Ingo Molnar wrote:
It will be only once per startup.
In that case it would be more efficient to make this part of the
binary execution environment so that exec() sets it up automatically,
not a separate prctl() syscall.
On 01/26/2014 12:39 AM, Ingo Molnar wrote:
>>
>> It will be only once per startup.
>
> In that case it would be more efficient to make this part of the
> binary execution environment so that exec() sets it up automatically,
> not a separate prctl() syscall.
>
This is not necessarily possible,
* Ren, Qiaowei wrote:
> The size of one bound table is 4M bytes for 64bit, and 16K bytes for
> 32bit. It can not be accessed by user-space, and it will be accessed
> automatically by hardware.
So, here's the bound-table allocation AFAICS:
+static bool allocate_bt(unsigned long bd_entry)
+{
Peter Zijlstra; Linus Torvalds; Andrew Morton
> Subject: Re: [PATCH v3 3/4] x86, mpx: add prctl commands PR_MPX_INIT,
> PR_MPX_RELEASE
>
>
> * Qiaowei Ren wrote:
>
> > @@ -7,6 +9,88 @@
> > #include
> > #include
> >
> > +static struct m
rg;
> linux-kernel@vger.kernel.org; Peter Zijlstra
> Subject: Re: [PATCH v3 3/4] x86, mpx: add prctl commands PR_MPX_INIT,
> PR_MPX_RELEASE
>
>
> * Ren Qiaowei wrote:
>
> > On 01/26/2014 04:22 PM, Ingo Molnar wrote:
> > >
> > >* Qiaowei Ren wrote:
>
* Qiaowei Ren wrote:
> @@ -7,6 +9,88 @@
> #include
> #include
>
> +static struct mmu_notifier mpx_mn;
> +static struct mmu_notifier_ops mpx_mmuops = {
> + .invalidate_range_end = mpx_invl_range_end,
> +};
> +
> +int mpx_init(struct task_struct *tsk)
> +{
> + if
* Ren Qiaowei wrote:
> On 01/26/2014 04:22 PM, Ingo Molnar wrote:
> >
> >* Qiaowei Ren wrote:
> >
> >>This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
> >>commands on the x86 platform. These commands can be used to
> >>init and release MPX related resource.
> >>
> >>A MMU notifier
On 01/26/2014 04:22 PM, Ingo Molnar wrote:
* Qiaowei Ren wrote:
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.
A MMU notifier will be registered during PR_MPX_INIT
command
* Qiaowei Ren wrote:
> This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
> commands on the x86 platform. These commands can be used to
> init and release MPX related resource.
>
> A MMU notifier will be registered during PR_MPX_INIT
> command execution. So the bound tables can be
* Qiaowei Ren qiaowei@intel.com wrote:
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.
A MMU notifier will be registered during PR_MPX_INIT
command execution. So the bound
On 01/26/2014 04:22 PM, Ingo Molnar wrote:
* Qiaowei Ren qiaowei@intel.com wrote:
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.
A MMU notifier will be registered during
* Ren Qiaowei qiaowei@intel.com wrote:
On 01/26/2014 04:22 PM, Ingo Molnar wrote:
* Qiaowei Ren qiaowei@intel.com wrote:
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.
* Qiaowei Ren qiaowei@intel.com wrote:
@@ -7,6 +9,88 @@
#include asm/fpu-internal.h
#include asm/alternative.h
+static struct mmu_notifier mpx_mn;
+static struct mmu_notifier_ops mpx_mmuops = {
+ .invalidate_range_end = mpx_invl_range_end,
+};
+
+int mpx_init(struct
; Peter Zijlstra
Subject: Re: [PATCH v3 3/4] x86, mpx: add prctl commands PR_MPX_INIT,
PR_MPX_RELEASE
* Ren Qiaowei qiaowei@intel.com wrote:
On 01/26/2014 04:22 PM, Ingo Molnar wrote:
* Qiaowei Ren qiaowei@intel.com wrote:
This patch adds the PR_MPX_INIT and PR_MPX_RELEASE
; Andrew Morton
Subject: Re: [PATCH v3 3/4] x86, mpx: add prctl commands PR_MPX_INIT,
PR_MPX_RELEASE
* Qiaowei Ren qiaowei@intel.com wrote:
@@ -7,6 +9,88 @@
#include asm/fpu-internal.h
#include asm/alternative.h
+static struct mmu_notifier mpx_mn;
+static struct
* Ren, Qiaowei qiaowei@intel.com wrote:
The size of one bound table is 4M bytes for 64bit, and 16K bytes for
32bit. It can not be accessed by user-space, and it will be accessed
automatically by hardware.
So, here's the bound-table allocation AFAICS:
+static bool allocate_bt(unsigned
On 01/26/2014 12:39 AM, Ingo Molnar wrote:
It will be only once per startup.
In that case it would be more efficient to make this part of the
binary execution environment so that exec() sets it up automatically,
not a separate prctl() syscall.
This is not necessarily possible, and in
On 01/27/2014 09:50 AM, H. Peter Anvin wrote:
On 01/26/2014 12:39 AM, Ingo Molnar wrote:
It will be only once per startup.
In that case it would be more efficient to make this part of the
binary execution environment so that exec() sets it up automatically,
not a separate prctl() syscall.
On 01/26/2014 11:14 PM, Ingo Molnar wrote:
* Ren, Qiaowei qiaowei@intel.com wrote:
The size of one bound table is 4M bytes for 64bit, and 16K bytes for
32bit. It can not be accessed by user-space, and it will be accessed
automatically by hardware.
So, here's the bound-table allocation
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
Peter, you mean we should remove these two call and do what they do in
user-space, right?
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled, all #BR exceptions are signals,
regardless of
On 01/27/2014 10:10 AM, H. Peter Anvin wrote:
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
Peter, you mean we should remove these two call and do what they do in
user-space, right?
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled, all
30 matches
Mail list logo
