On Sat, Jul 12, 2014 at 2:17 PM, Andy Lutomirski wrote:
> On Sat, Jul 12, 2014 at 11:52 AM, Andi Kleen wrote:
>> On Sat, Jul 12, 2014 at 11:40:03AM -0700, H. Peter Anvin wrote:
>>> Because you are doing something weird (like Pin, for example) and take an
>>> asynchronous fault?
>>
>> But even fo
On Sat, Jul 12, 2014 at 11:52 AM, Andi Kleen wrote:
> On Sat, Jul 12, 2014 at 11:40:03AM -0700, H. Peter Anvin wrote:
>> Because you are doing something weird (like Pin, for example) and take an
>> asynchronous fault?
>
> But even for pin that would need executing 16 bit code, or really weird
> 3
On Sat, Jul 12, 2014 at 11:40:03AM -0700, H. Peter Anvin wrote:
> Because you are doing something weird (like Pin, for example) and take an
> asynchronous fault?
But even for pin that would need executing 16 bit code, or really weird
32bit code. AFAIK for 32bit the only good use case was NX emula
Because you are doing something weird (like Pin, for example) and take an
asynchronous fault?
On July 12, 2014 11:37:48 AM PDT, Andi Kleen wrote:
>> This seems like it's asking for trouble. I think wxe'd have to
>> separately save the selectors and the base registers to avoid
>breaking
>> somet
> This seems like it's asking for trouble. I think wxe'd have to
> separately save the selectors and the base registers to avoid breaking
> something, especially once wrgsbase, etc are enabled.
I agree, it would likely break existing code.
> Linus, for context, the other patch in this series sav
On Jul 11, 2014 7:21 PM, "Linus Torvalds" wrote:
>
> On Fri, Jul 11, 2014 at 9:29 AM, Andy Lutomirski wrote:
> > As far as I can tell, these fields have been set to zero on save and
> > ignored on restore since Linux was imported into git. Rename them
> > '__pad1' and '__pad2' to avoid confusion
Our current handling of fs/vs is really weird. The best may very well be to
explicitly save and restore both fs and he as part of Andi's patchset to
support wrxsbase.
On July 11, 2014 7:21:54 PM PDT, Linus Torvalds
wrote:
>On Fri, Jul 11, 2014 at 9:29 AM, Andy Lutomirski
>wrote:
>> As far as
On Fri, Jul 11, 2014 at 9:29 AM, Andy Lutomirski wrote:
> As far as I can tell, these fields have been set to zero on save and
> ignored on restore since Linux was imported into git. Rename them
> '__pad1' and '__pad2' to avoid confusion and to allow them to be
> recycled some day.
Shouldn't we
On 07/11/2014 11:39 AM, Andy Lutomirski wrote:
> On Fri, Jul 11, 2014 at 11:12 AM, Andi Kleen wrote:
>>> diff --git a/arch/x86/include/uapi/asm/sigcontext.h
>>> b/arch/x86/include/uapi/asm/sigcontext.h
>>> index 076b11f..df9908b 100644
>>> --- a/arch/x86/include/uapi/asm/sigcontext.h
>>> +++ b/ar
On 07/11/2014 09:29 AM, Andy Lutomirski wrote:
> diff --git a/arch/x86/include/uapi/asm/sigcontext.h
> b/arch/x86/include/uapi/asm/sigcontext.h
> index 076b11f..df9908b 100644
> --- a/arch/x86/include/uapi/asm/sigcontext.h
> +++ b/arch/x86/include/uapi/asm/sigcontext.h
> @@ -177,8 +177,8 @@ struct
On Fri, Jul 11, 2014 at 11:12 AM, Andi Kleen wrote:
>> diff --git a/arch/x86/include/uapi/asm/sigcontext.h
>> b/arch/x86/include/uapi/asm/sigcontext.h
>> index 076b11f..df9908b 100644
>> --- a/arch/x86/include/uapi/asm/sigcontext.h
>> +++ b/arch/x86/include/uapi/asm/sigcontext.h
>
> I don't think
> diff --git a/arch/x86/include/uapi/asm/sigcontext.h
> b/arch/x86/include/uapi/asm/sigcontext.h
> index 076b11f..df9908b 100644
> --- a/arch/x86/include/uapi/asm/sigcontext.h
> +++ b/arch/x86/include/uapi/asm/sigcontext.h
I don't think renaming fields in uapi/asm is acceptable. These
are likely
12 matches
Mail list logo
