> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, January 13, 2014 6:43 PM
> To: Ren, Qiaowei
> Cc: H. Peter Anvin; Thomas Gleixner; Ingo Molnar; x...@kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 5/5] x86, mpx: ext
-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, January 13, 2014 6:43 PM
To: Ren, Qiaowei
Cc: H. Peter Anvin; Thomas Gleixner; Ingo Molnar; x...@kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] x86, mpx: extend siginfo structure
On Mon, Jan 13, 2014 at 04:22:27PM +0800, Ren Qiaowei wrote:
> >I tried to use generic structure and macro, but many members of generic
> >struct insn are not used for MPX,
I think that's ok - there are a lot of examples in the kernel where only
a subset of the struct members are used by a
On 01/13/2014 11:09 AM, Ren Qiaowei wrote:
On 01/13/2014 01:03 AM, Borislav Petkov wrote:
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
I saw a previous version of the code that did that, and it really
didn't work out well -- it ended up being more complex and slower.
I
On 01/13/2014 11:09 AM, Ren Qiaowei wrote:
On 01/13/2014 01:03 AM, Borislav Petkov wrote:
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
I saw a previous version of the code that did that, and it really
didn't work out well -- it ended up being more complex and slower.
I
On Mon, Jan 13, 2014 at 04:22:27PM +0800, Ren Qiaowei wrote:
I tried to use generic structure and macro, but many members of generic
struct insn are not used for MPX,
I think that's ok - there are a lot of examples in the kernel where only
a subset of the struct members are used by a particular
On 01/13/2014 01:03 AM, Borislav Petkov wrote:
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
I saw a previous version of the code that did that, and it really
didn't work out well -- it ended up being more complex and slower.
I suspected as much.
But, we still probably
On 01/12/2014 09:03 AM, Borislav Petkov wrote:
> On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
>> I saw a previous version of the code that did that, and it really
>> didn't work out well -- it ended up being more complex and slower.
>
> I suspected as much.
>
> But, we still
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
> I saw a previous version of the code that did that, and it really
> didn't work out well -- it ended up being more complex and slower.
I suspected as much.
But, we still probably should use the generic struct insn, insn_field,
etc
>
> This thing looks like a partial duplication of functionality which we
> already have - inat.*/insn.*, etc.
>
> It would be cleaner to integrate the mpx pieces into the existing x86
> insn analysis code and use it instead of growing your own, IMHO.
>
I saw a previous version of the code
On Sun, Jan 12, 2014 at 05:20:03PM +0800, Qiaowei Ren wrote:
> This patch adds new fields about bound violation into siginfo
> structure. si_lower and si_upper are respectively lower bound
> and upper bound when bound violation is caused.
>
> These fields will be set in #BR exception handler by
On Sun, Jan 12, 2014 at 05:20:03PM +0800, Qiaowei Ren wrote:
This patch adds new fields about bound violation into siginfo
structure. si_lower and si_upper are respectively lower bound
and upper bound when bound violation is caused.
These fields will be set in #BR exception handler by
This thing looks like a partial duplication of functionality which we
already have - inat.*/insn.*, etc.
It would be cleaner to integrate the mpx pieces into the existing x86
insn analysis code and use it instead of growing your own, IMHO.
I saw a previous version of the code that did
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
I saw a previous version of the code that did that, and it really
didn't work out well -- it ended up being more complex and slower.
I suspected as much.
But, we still probably should use the generic struct insn, insn_field,
etc
On 01/12/2014 09:03 AM, Borislav Petkov wrote:
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
I saw a previous version of the code that did that, and it really
didn't work out well -- it ended up being more complex and slower.
I suspected as much.
But, we still probably
On 01/13/2014 01:03 AM, Borislav Petkov wrote:
On Sun, Jan 12, 2014 at 08:49:21AM -0800, H. Peter Anvin wrote:
I saw a previous version of the code that did that, and it really
didn't work out well -- it ended up being more complex and slower.
I suspected as much.
But, we still probably
16 matches
Mail list logo
