On Fri, Jul 31, 2015 at 5:47 AM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>>
>> > I fixed this up.
>>
>> Another build fix was needed for:
>>
>> arch/x86/mm/fault.c: In function ‘check_v8086_mode’:
>> arch/x86/mm/fault.c:319:39: error: ‘struct thread_struct’ has no member
>> named ‘vm86
* Ingo Molnar wrote:
>
> > I fixed this up.
>
> Another build fix was needed for:
>
> arch/x86/mm/fault.c: In function ‘check_v8086_mode’:
> arch/x86/mm/fault.c:319:39: error: ‘struct thread_struct’ has no member
> named ‘vm86’
>
> that's on 32-bit defconfig.
A third one occurs in:
d
* Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
> > --- a/arch/x86/include/asm/vm86.h
> > +++ b/arch/x86/include/asm/vm86.h
>
> > +static inline void save_v86_state(struct kernel_vm86_regs *, int) { }
> > +
>
> So this is not a valid inline function and the patches were clearly not built
>
* Brian Gerst wrote:
> --- a/arch/x86/include/asm/vm86.h
> +++ b/arch/x86/include/asm/vm86.h
> +static inline void save_v86_state(struct kernel_vm86_regs *, int) { }
> +
So this is not a valid inline function and the patches were clearly not built
with
!VM86 such as 64-bit defconfig:
In fi
On Wed, Jul 29, 2015 at 10:47 AM, Linus Torvalds
wrote:
> On Wed, Jul 29, 2015 at 10:36 AM, Brian Gerst wrote:
>>
>> I think I remember now what the issue was. Since entering vm86 mode
>> uses force_iret(), the work_pending code path was being taken. I had
>> to move the call to save_v86_state
On Wed, Jul 29, 2015 at 10:36 AM, Brian Gerst wrote:
>
> I think I remember now what the issue was. Since entering vm86 mode
> uses force_iret(), the work_pending code path was being taken. I had
> to move the call to save_v86_state out of here to handle_signal(),
> otherwise it would just resto
On Wed, Jul 29, 2015 at 1:16 PM, Linus Torvalds
wrote:
> On Wed, Jul 29, 2015 at 10:14 AM, Brian Gerst wrote:
>>
>> I think it was causing signal handling to fail, but I can't remember
>> exactly.
>
> Ugh.
>
> If that hunk made a difference, then there is something wrong with
> your patch-series.
On Wed, Jul 29, 2015 at 10:14 AM, Brian Gerst wrote:
>
> I think it was causing signal handling to fail, but I can't remember
> exactly.
Ugh.
If that hunk made a difference, then there is something wrong with
your patch-series. So please double-check.
Linus
--
To unsubscribe fro
On Wed, Jul 29, 2015 at 11:50 AM, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 10:41 PM, Brian Gerst wrote:
>> Change to use the normal pt_regs area to enter and exit vm86 mode. This is
>> done by increasing the padding at the top of the stack to make room for the
>> extra vm86 segment slots
On Tue, Jul 28, 2015 at 10:41 PM, Brian Gerst wrote:
> Change to use the normal pt_regs area to enter and exit vm86 mode. This is
> done by increasing the padding at the top of the stack to make room for the
> extra vm86 segment slots in the IRET frame. It then saves the 32-bit regs
> in the off
Change to use the normal pt_regs area to enter and exit vm86 mode. This is
done by increasing the padding at the top of the stack to make room for the
extra vm86 segment slots in the IRET frame. It then saves the 32-bit regs
in the off-stack vm86 data, and copies in the vm86 regs. Exiting back t
11 matches
Mail list logo
