Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Jon Foster]

Hi,

> The other thing I've found printks to hide before is timing bugs / races.
> Unfortunately I can't see one here, but maybe someone else can ;-)
> Maybe inserting a 1ms delay or something in place of the printk would
> have the same effect?

One of my colleagues had an interesting bug caused by an
uninitialized variable - a printk() in the right place happened
to set the variable (which gcc had put in a register) to the
correct value for his code to work.

I've tried looking for uses of uninitialized registers in entry.S,
but the assembly there isn't easy to follow.

What happens if you replace the printk with assembly code
that clobbers eax, ecx, edx and (most of) eflags?  (Assuming
I've remembered the calling convention correctly, those are
the registers that printk will be overwriting).

Kind regards,

Jon

Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Jon Foster wrote:

> > The other thing I've found printks to hide before is timing bugs / races.
> > Unfortunately I can't see one here, but maybe someone else can ;-)
> > Maybe inserting a 1ms delay or something in place of the printk would
> > have the same effect?
> 
> One of my colleagues had an interesting bug caused by an
> uninitialized variable - a printk() in the right place happened
> to set the variable (which gcc had put in a register) to the
> correct value for his code to work.

Very nice =)

> I've tried looking for uses of uninitialized registers in entry.S,
> but the assembly there isn't easy to follow.

I've walked that code and can't see anything wrong anywhere.

> What happens if you replace the printk with assembly code
> that clobbers eax, ecx, edx and (most of) eflags?  (Assuming
> I've remembered the calling convention correctly, those are
> the registers that printk will be overwriting).

Well i have tried a number of heavyweight functions, so far none of them 
have had the effect that a printk has had. It's also worth noting that a 
printk lookalike function such as the following, does not fix things 
either.

asmlinkage int kooh_la_la(const char *fmt, ...)
{
	return strlen(fmt);
}

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Andrew Morton]

Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
>
>  I've walked that code and can't see anything wrong anywhere.

fwiw, X comes up happily on a couple of boxes here, with the 4g/4g split
enabled.

Have you tried a different compiler?

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Andrew Morton wrote:

> Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
> >
> >  I've walked that code and can't see anything wrong anywhere.
> 
> fwiw, X comes up happily on a couple of boxes here, with the 4g/4g split
> enabled.

The exact same kernel runs fine on my other test boxes. But i really don't 
have faith in this compiler, it's the same one which constantly seems to be 
tripping into various problems.

> Have you tried a different compiler?

I just tried the RH9 2.96 and it also triple faulted. Oh my.. The only 
unique thing about this hardware compared ot the other stuff i have here 
is that it's an AMD K6. Everything else is Intel.

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Linus Torvalds]

On Wed, 19 Nov 2003, Zwane Mwaikambo wrote:
> 
> I just tried the RH9 2.96 and it also triple faulted. Oh my.. The only 
> unique thing about this hardware compared ot the other stuff i have here 
> is that it's an AMD K6. Everything else is Intel.

Different TLB sizes (and organizations) etc can _easily_ matter, if the 
Intel one just happens to work because something stays in the TLB while 
the page table mapping is incorrect and keeps the system afloat.

Or - and in this case more likely - since the problem is fixed by running
a (complex) thing that trashes all over the DTLB/ITLB, it's more likely
that there might be a _missing_ TLB invalidate somewhere, and that the
Intel boxes stay up because they have a smaller TLB and the stale entry
gets flushed out early from them.

But you already tried a "flush_tlb_all()" which _should_ have flushed
absolutely everything, including global tables. I dunno. It could be
hitting a CPU bug too, of course. 

It would be interesting to hear if other K6 users see problems..

			Linus

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Matt Mackall]

On Thu, Nov 20, 2003 at 01:44:05AM -0600, Matt Mackall wrote:
> On Wed, Nov 19, 2003 at 05:09:28PM -0600, Matt Mackall wrote:
> > On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote:
> > > 
> > > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my
> > > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit
> > > doesn't help. So my suspicion is that the printk is changing the
> > > timing just enough on Zwane's box that he's getting a timer interrupt
> > > knocking him out of vm86 mode before he hits a fatal bit in the fault
> > > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault,
> > > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so
> > > there's probably something amiss in the trampoline code.
> > 
> > Some more datapoints:
> > 
> > CPU          distro          compiler  video        X     result
> > K6-2/500     connectiva 9    2.96      trident      4.3   reboot (zwane)
> > K6-2/500     connectiva 9    3.2.2     trident      4.3   reboot (zwane)
> > Opteron 240  debian unstable 3.2       S3           4.2.1 reboot
> > Athlon 2100  debian unstable 3.2       radeon 7500  4.2.1 works
> > P4M 1800     debian unstable 3.2       radeon m7    4.2.1 reboot
> 
> And indeed it does turn out to be a problem with the trampoline
> mechanics. The fix for -mm4:

Cleanup, as pointed out by Zwane:

Fix triple faulting on some boxes with 4G/4G


 mm-mpm/arch/i386/kernel/vm86.c |    3 +--
 1 files changed, 1 insertion(+), 2 deletions(-)

diff -puN arch/i386/kernel/vm86.c~virtual-esp arch/i386/kernel/vm86.c
--- mm/arch/i386/kernel/vm86.c~virtual-esp	2003-11-20 01:36:32.000000000 -0600
+++ mm-mpm/arch/i386/kernel/vm86.c	2003-11-20 02:08:38.000000000 -0600
@@ -303,10 +303,9 @@ static void do_sys_vm86(struct kernel_vm
 
 	tss = init_tss + get_cpu();
 	tsk->thread.esp0 = (unsigned long) &info->VM86_TSS_ESP0;
-	tss->esp0 = virtual_esp0(tsk);
 	if (cpu_has_sep)
 		tsk->thread.sysenter_cs = 0;
-	load_esp0(tss, &tsk->thread);
+	load_virtual_esp0(tss, tsk);
 	put_cpu();
 
 	tsk->thread.screen_bitmap = info->screen_bitmap;

_



-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Andrew Morton]

Matt Mackall <mpm@selenic.com> wrote:
>
>  -	load_esp0(tss, &tsk->thread);
>  +	load_virtual_esp0(tss, tsk);

Thanks guys.

Now I'll have to put something else in there to keep you amused ;)

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Matt Mackall]

On Wed, Nov 19, 2003 at 05:09:28PM -0600, Matt Mackall wrote:
> On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote:
> > 
> > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my
> > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit
> > doesn't help. So my suspicion is that the printk is changing the
> > timing just enough on Zwane's box that he's getting a timer interrupt
> > knocking him out of vm86 mode before he hits a fatal bit in the fault
> > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault,
> > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so
> > there's probably something amiss in the trampoline code.
> 
> Some more datapoints:
> 
> CPU          distro          compiler  video        X     result
> K6-2/500     connectiva 9    2.96      trident      4.3   reboot (zwane)
> K6-2/500     connectiva 9    3.2.2     trident      4.3   reboot (zwane)
> Opteron 240  debian unstable 3.2       S3           4.2.1 reboot
> Athlon 2100  debian unstable 3.2       radeon 7500  4.2.1 works
> P4M 1800     debian unstable 3.2       radeon m7    4.2.1 reboot

And indeed it does turn out to be a problem with the trampoline
mechanics. The fix for -mm4:


Fix triple faulting on some boxes with 4G/4G


 mm-mpm/arch/i386/kernel/vm86.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN arch/i386/kernel/vm86.c~virtual-esp arch/i386/kernel/vm86.c
--- mm/arch/i386/kernel/vm86.c~virtual-esp	2003-11-20 01:36:32.000000000 -0600
+++ mm-mpm/arch/i386/kernel/vm86.c	2003-11-20 01:36:32.000000000 -0600
@@ -306,7 +306,7 @@ static void do_sys_vm86(struct kernel_vm
 	tss->esp0 = virtual_esp0(tsk);
 	if (cpu_has_sep)
 		tsk->thread.sysenter_cs = 0;
-	load_esp0(tss, &tsk->thread);
+	load_virtual_esp0(tss, tsk);
 	put_cpu();
 
 	tsk->thread.screen_bitmap = info->screen_bitmap;

_
 

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Wed, 19 Nov 2003, Matt Mackall wrote:

> On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote:
> > 
> > Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my
> > 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit
> > doesn't help. So my suspicion is that the printk is changing the
> > timing just enough on Zwane's box that he's getting a timer interrupt
> > knocking him out of vm86 mode before he hits a fatal bit in the fault
> > handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault,
> > do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so
> > there's probably something amiss in the trampoline code.
> 
> Some more datapoints:

Thanks for trying those out, i got another one to add.

> CPU          distro          compiler  video        X     result
> K6-2/500     connectiva 9    2.96      trident      4.3   reboot (zwane)
> K6-2/500     connectiva 9    3.2.2     trident      4.3   reboot (zwane)
> Opteron 240  debian unstable 3.2       S3           4.2.1 reboot
> Athlon 2100  debian unstable 3.2       radeon 7500  4.2.1 works
> P4M 1800     debian unstable 3.2       radeon m7    4.2.1 reboot

P4/Xeon 2000	Fedora Core 1	3.3.2	ATI Rage XL	4.3.0 reboot

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Matt Mackall]

On Wed, Nov 19, 2003 at 02:32:10PM -0600, Matt Mackall wrote:
> 
> Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my
> 1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit
> doesn't help. So my suspicion is that the printk is changing the
> timing just enough on Zwane's box that he's getting a timer interrupt
> knocking him out of vm86 mode before he hits a fatal bit in the fault
> handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault,
> do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so
> there's probably something amiss in the trampoline code.

Some more datapoints:

CPU          distro          compiler  video        X     result
K6-2/500     connectiva 9    2.96      trident      4.3   reboot (zwane)
K6-2/500     connectiva 9    3.2.2     trident      4.3   reboot (zwane)
Opteron 240  debian unstable 3.2       S3           4.2.1 reboot
Athlon 2100  debian unstable 3.2       radeon 7500  4.2.1 works
P4M 1800     debian unstable 3.2       radeon m7    4.2.1 reboot

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Matt Mackall]

On Tue, Nov 18, 2003 at 08:37:25AM -0800, Linus Torvalds wrote:
> 
> On Tue, 18 Nov 2003, Zwane Mwaikambo wrote:
> > 
> > Here are diffs from the do_sys_vm86 only.
> 
> Ok. Much more readable.
> 
> And there is something very suspicious there.
> 
> The code with and without the printk() looks _identical_ apart from some 
> trivial label renumbering, and the added
> 
> 	pushl   $.LC6
> 	call    printk
> 	.. asm ..
> 	popl %esi
> 
> which all looks fine (esi is dead at that point, so the compiler is just
> using a "popl" as a shorter form of "addl $4,%esp").
> 
> Btw, you seem to compile with debugging, which makes the assembly 
> language pretty much unreadable and accounts for most of the 
> differences: the line numbers change. If you compile a kernel where the 
> line numbers don't change (by commenting _out_ the printk rather than 
> removing the whole line), your diff would be more readable.
> 
> Anyway, there are _zero_ differences.
> 
> Just for fun, try this: move the "printk()" to _below_ the "asm"  
> statement. It will never actually get executed, but if it's an issue of
> some subtle code or data placement things (cache lines etc), maybe that
> also hides the oops, since all the same code and data will be generated, 
> just not run...

Zwane's got a K6-2 500MHz. I've just managed to reproduce this on my
1.4GHz Opteron box (with Debian gcc 3.2). Here, the "ooh la la" bit
doesn't help. So my suspicion is that the printk is changing the
timing just enough on Zwane's box that he's getting a timer interrupt
knocking him out of vm86 mode before he hits a fatal bit in the fault
handling path for 4/4. Printks in handle_vm86_trap, handle_vm86_fault,
do_trap:vm86_trap, and do_general_protection:gp_in_vm86 never fire so
there's probably something amiss in the trampoline code.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Martin J. Bligh]

>> Btw, you seem to compile with debugging, which makes the assembly 
>> language pretty much unreadable and accounts for most of the 
>> differences: the line numbers change. If you compile a kernel where the 
>> line numbers don't change (by commenting _out_ the printk rather than 
>> removing the whole line), your diff would be more readable.
> 
> Aha! Thanks for mentioning that, noted.
> 
>> Anyway, there are _zero_ differences.
>> 
>> Just for fun, try this: move the "printk()" to _below_ the "asm"  
>> statement. It will never actually get executed, but if it's an issue of
>> some subtle code or data placement things (cache lines etc), maybe that
>> also hides the oops, since all the same code and data will be generated, 
>> just not run...
> 
> Ok i just tried that and it still fails. Matt Mackall suggested i also try 
> writing a minimal printk which has the same effect.

The other thing I've found printks to hide before is timing bugs / races.
Unfortunately I can't see one here, but maybe someone else can ;-)
Maybe inserting a 1ms delay or something in place of the printk would
have the same effect?

M.

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Martin J. Bligh wrote:

> The other thing I've found printks to hide before is timing bugs / races.
> Unfortunately I can't see one here, but maybe someone else can ;-)
> Maybe inserting a 1ms delay or something in place of the printk would
> have the same effect?

I've tried a number of timing related workarounds, namely;
schedule_timeout(2*HZ) and some long spinning loops. I've also thrown a 
schedule() in there at some point.

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Linus Torvalds wrote:

> Ok. Much more readable.
> 
> And there is something very suspicious there.
> 
> The code with and without the printk() looks _identical_ apart from some 
> trivial label renumbering, and the added
> 
> 	pushl   $.LC6
> 	call    printk
> 	.. asm ..
> 	popl %esi
> 
> which all looks fine (esi is dead at that point, so the compiler is just
> using a "popl" as a shorter form of "addl $4,%esp").
> 
> Btw, you seem to compile with debugging, which makes the assembly 
> language pretty much unreadable and accounts for most of the 
> differences: the line numbers change. If you compile a kernel where the 
> line numbers don't change (by commenting _out_ the printk rather than 
> removing the whole line), your diff would be more readable.

Aha! Thanks for mentioning that, noted.

> Anyway, there are _zero_ differences.
> 
> Just for fun, try this: move the "printk()" to _below_ the "asm"  
> statement. It will never actually get executed, but if it's an issue of
> some subtle code or data placement things (cache lines etc), maybe that
> also hides the oops, since all the same code and data will be generated, 
> just not run...

Ok i just tried that and it still fails. Matt Mackall suggested i also try 
writing a minimal printk which has the same effect.

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Linus Torvalds]

On Tue, 18 Nov 2003, Zwane Mwaikambo wrote:
> 
> Here are diffs from the do_sys_vm86 only.

Ok. Much more readable.

And there is something very suspicious there.

The code with and without the printk() looks _identical_ apart from some 
trivial label renumbering, and the added

	pushl   $.LC6
	call    printk
	.. asm ..
	popl %esi

which all looks fine (esi is dead at that point, so the compiler is just
using a "popl" as a shorter form of "addl $4,%esp").

Btw, you seem to compile with debugging, which makes the assembly 
language pretty much unreadable and accounts for most of the 
differences: the line numbers change. If you compile a kernel where the 
line numbers don't change (by commenting _out_ the printk rather than 
removing the whole line), your diff would be more readable.

Anyway, there are _zero_ differences.

Just for fun, try this: move the "printk()" to _below_ the "asm"  
statement. It will never actually get executed, but if it's an issue of
some subtle code or data placement things (cache lines etc), maybe that
also hides the oops, since all the same code and data will be generated, 
just not run...

		Linus

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Linus Torvalds wrote:

> Hmm. I don't see anything. However, it's a lot easier to read the
> gcc-generated assembly ("make arch/i386/kernel/vm86.s") than it is to read
> the objdump disassembly.
>
> 
> It's also a lot easier to see what the assembly language is when giving 
> the
> 
> 	-fno-reorder-blocks

I'll recompile and verify that the bug can be reproduced and worked around 
with that flag.
 
> switch to gcc. Without it, modern gcc's tend to have _way_ too many jumps 
> around. But maybe that actually changes the behaviour too.

Here are diffs from the do_sys_vm86 only.

--- asm-before	2003-11-18 10:56:02.967643808 -0500
+++ asm-after	2003-11-18 10:55:37.880457640 -0500
@@ -897,6 +897,10 @@
 .LFE473:
 .Lfe4:
 	.size	sys_vm86,.Lfe4-sys_vm86
+	.section	.rodata.str1.1
+.LC6:
+	.string	"ooh la la\n"
+	.text
 	.p2align 4,,15
 	.type	do_sys_vm86,@function
 do_sys_vm86:
@@ -1053,29 +1057,37 @@
 	jne	.L213
 .L210:
 	.loc 1 315 0
+	pushl	$.LC6
+.LCFI98:
+	call	printk
+	.loc 1 316 0
 	movl	4(%esi), %edx
 #APP
 	xorl %eax,%eax; movl %eax,%fs; movl %eax,%gs
 	movl %edi,%esp
 	movl %edx,%ebp
 	jmp resume_userspace
-	.loc 1 323 0
 #NO_APP
-	popl	%ebx
-.LCFI98:
+.LBE53:
 	popl	%esi
 .LCFI99:
-	popl	%edi
+	.loc 1 324 0
+	popl	%ebx
 .LCFI100:
+	popl	%esi
+.LCFI101:
+	popl	%edi
+.LCFI102:
 	ret
 	.loc 1 313 0
 	.p2align 4,,7
 .L213:
+.LBB65:
 	pushl	%esi
-.LCFI101:
+.LCFI103:
 	call	mark_screen_rdonly
 	popl	%eax
-.LCFI102:
+.LCFI104:
 	jmp	.L210
 	.loc 1 310 0
 .L212:
@@ -1083,7 +1095,7 @@
 	jmp	.L197
 	.loc 14 454 0
 .L211:
-.LBB65:
+.LBB66:
 	movw	36(%edx), %ax
 	movw	%ax, 16(%ecx)
 	.loc 14 455 0
@@ -1097,7 +1109,7 @@
 	.p2align 4,,7
 .L183:
 	.loc 1 283 0
-.LBE65:
+.LBE66:
 	movl	$0, 1468(%esi)
 	.loc 1 284 0
 	jmp	.L182
@@ -1115,7 +1127,7 @@
 	movl	$28672, 1468(%esi)
 	.loc 1 287 0
 	jmp	.L182
-.LBE53:
+.LBE65:
 .LFE475:
 .Lfe5:
 	.size	do_sys_vm86,.Lfe5-do_sys_vm86

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Linus Torvalds]

On Tue, 18 Nov 2003, Zwane Mwaikambo wrote:
> 
> Another note from our avian friends; i seem to have sent a slightly 
> different dump from the patch, although they do both achieve the same 
> effect. I shall append it for completeness.

Hmm. I don't see anything. However, it's a lot easier to read the
gcc-generated assembly ("make arch/i386/kernel/vm86.s") than it is to read
the objdump disassembly.

It's also a lot easier to see what the assembly language is when giving 
the

	-fno-reorder-blocks

switch to gcc. Without it, modern gcc's tend to have _way_ too many jumps 
around. But maybe that actually changes the behaviour too.

		Linus

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Mon, 17 Nov 2003, Zwane Mwaikambo wrote:

> A little bird told me to send diffs... But there is a lot of noise due to 
> offsets i'm afraid.

Another note from our avian friends; i seem to have sent a slightly 
different dump from the patch, although they do both achieve the same 
effect. I shall append it for completeness.

0x0210e860 <do_sys_vm86+0>:     push   %edi
0x0210e861 <do_sys_vm86+1>:     mov    $0xffffe000,%eax
0x0210e866 <do_sys_vm86+6>:     push   %esi
0x0210e867 <do_sys_vm86+7>:     and    %esp,%eax
0x0210e869 <do_sys_vm86+9>:     push   %ebx
0x0210e86a <do_sys_vm86+10>:    mov    0x10(%esp,1),%edi
0x0210e86e <do_sys_vm86+14>:    mov    0x14(%esp,1),%esi
0x0210e872 <do_sys_vm86+18>:    movl   $0x0,0x1c(%edi)
0x0210e879 <do_sys_vm86+25>:    movl   $0x0,0x20(%edi)
0x0210e880 <do_sys_vm86+32>:    mov    (%eax),%edx
0x0210e882 <do_sys_vm86+34>:    mov    0x30(%edi),%eax
0x0210e885 <do_sys_vm86+37>:    mov    %eax,0x5b8(%edx)
0x0210e88b <do_sys_vm86+43>:    mov    0x30(%edi),%edx
0x0210e88e <do_sys_vm86+46>:    mov    0xbc(%edi),%eax
0x0210e894 <do_sys_vm86+52>:    and    $0xdd5,%edx
0x0210e89a <do_sys_vm86+58>:    mov    %edx,0x30(%edi)
0x0210e89d <do_sys_vm86+61>:    mov    0x30(%eax),%eax
0x0210e8a0 <do_sys_vm86+64>:    and    $0xfffff22a,%eax
0x0210e8a5 <do_sys_vm86+69>:    or     %eax,%edx
0x0210e8a7 <do_sys_vm86+71>:    mov    0x54(%edi),%eax
0x0210e8aa <do_sys_vm86+74>:    or     $0x20000,%edx
0x0210e8b0 <do_sys_vm86+80>:    cmp    $0x3,%eax
0x0210e8b3 <do_sys_vm86+83>:    mov    %edx,0x30(%edi)
0x0210e8b6 <do_sys_vm86+86>:    je     0x210e9f0 <do_sys_vm86+400>
0x0210e8bc <do_sys_vm86+92>:    cmp    $0x3,%eax
0x0210e8bf <do_sys_vm86+95>:    ja     0x210e9d5 <do_sys_vm86+373>
0x0210e8c5 <do_sys_vm86+101>:   cmp    $0x2,%eax
0x0210e8c8 <do_sys_vm86+104>:   je     0x210e9c6 <do_sys_vm86+358>
0x0210e8ce <do_sys_vm86+110>:   movl   $0x247000,0x5bc(%esi)
0x0210e8d8 <do_sys_vm86+120>:   mov    0xbc(%edi),%eax
0x0210e8de <do_sys_vm86+126>:   movl   $0x0,0x18(%eax)
0x0210e8e5 <do_sys_vm86+133>:   mov    0x360(%esi),%eax
0x0210e8eb <do_sys_vm86+139>:   mov    %eax,0x5c0(%esi)
0x0210e8f1 <do_sys_vm86+145>:   movl   %fs,0x5c4(%esi)
0x0210e8f7 <do_sys_vm86+151>:   movl   %gs,0x5c8(%esi)
0x0210e8fd <do_sys_vm86+157>:   mov    $0xffffe000,%ebx
0x0210e902 <do_sys_vm86+162>:   and    %esp,%ebx
0x0210e904 <do_sys_vm86+164>:   mov    0x14(%ebx),%eax
0x0210e907 <do_sys_vm86+167>:   inc    %eax
0x0210e908 <do_sys_vm86+168>:   mov    %eax,0x14(%ebx)
0x0210e90b <do_sys_vm86+171>:   mov    0x10(%ebx),%eax
0x0210e90e <do_sys_vm86+174>:   mov    0x4(%esi),%edx
0x0210e911 <do_sys_vm86+177>:   shl    $0x9,%eax
0x0210e914 <do_sys_vm86+180>:   lea    0x26ff000(%eax),%ecx
0x0210e91a <do_sys_vm86+186>:   lea    0x4c(%edi),%eax
0x0210e91d <do_sys_vm86+189>:   mov    %eax,0x360(%esi)
0x0210e923 <do_sys_vm86+195>:   sub    0x1c(%edx),%eax
0x0210e926 <do_sys_vm86+198>:   add    0x20(%edx),%eax
0x0210e929 <do_sys_vm86+201>:   mov    %eax,0x4(%ecx)
0x0210e92c <do_sys_vm86+204>:   mov    0x25fe52c,%eax
0x0210e931 <do_sys_vm86+209>:   test   $0x800,%eax
0x0210e936 <do_sys_vm86+214>:   je     0x210e942 <do_sys_vm86+226>
0x0210e938 <do_sys_vm86+216>:   movl   $0x0,0x364(%esi)
0x0210e942 <do_sys_vm86+226>:   lea    0x340(%esi),%edx
0x0210e948 <do_sys_vm86+232>:   mov    0x20(%edx),%eax
0x0210e94b <do_sys_vm86+235>:   mov    %eax,0x4(%ecx)
0x0210e94e <do_sys_vm86+238>:   mov    0x10(%ecx),%ax
0x0210e952 <do_sys_vm86+242>:   and    $0xffff,%eax
0x0210e957 <do_sys_vm86+247>:   cmp    0x24(%edx),%eax
0x0210e95a <do_sys_vm86+250>:   jne    0x210e9b0 <do_sys_vm86+336>
0x0210e95c <do_sys_vm86+252>:   mov    0x14(%ebx),%eax
0x0210e95f <do_sys_vm86+255>:   dec    %eax
0x0210e960 <do_sys_vm86+256>:   mov    %eax,0x14(%ebx)
0x0210e963 <do_sys_vm86+259>:   mov    0x8(%ebx),%eax
0x0210e966 <do_sys_vm86+262>:   and    $0x8,%eax
0x0210e969 <do_sys_vm86+265>:   jne    0x210e9a9 <do_sys_vm86+329>
0x0210e96b <do_sys_vm86+267>:   mov    0x50(%edi),%eax
0x0210e96e <do_sys_vm86+270>:   mov    %eax,0x5b4(%esi)
0x0210e974 <do_sys_vm86+276>:   testb  $0x1,0x4c(%edi)
0x0210e978 <do_sys_vm86+280>:   jne    0x210e9a0 <do_sys_vm86+320>
0x0210e97a <do_sys_vm86+282>:   push   $0x255f121
0x0210e97f <do_sys_vm86+287>:   call   0x21285a0 <printk>
0x0210e984 <do_sys_vm86+292>:   mov    0x4(%esi),%edx
0x0210e987 <do_sys_vm86+295>:   xor    %eax,%eax
0x0210e989 <do_sys_vm86+297>:   mov    %eax,%fs
0x0210e98b <do_sys_vm86+299>:   mov    %eax,%gs
0x0210e98d <do_sys_vm86+301>:   mov    %edi,%esp
0x0210e98f <do_sys_vm86+303>:   mov    %edx,%ebp
0x0210e991 <do_sys_vm86+305>:   jmp    0xfffeb100 <resume_userspace>
0x0210e996 <do_sys_vm86+310>:   pop    %esi
0x0210e997 <do_sys_vm86+311>:   pop    %ebx
0x0210e998 <do_sys_vm86+312>:   pop    %esi
0x0210e999 <do_sys_vm86+313>:   pop    %edi
0x0210e99a <do_sys_vm86+314>:   ret
0x0210e99b <do_sys_vm86+315>:   nop
0x0210e99c <do_sys_vm86+316>:   lea    0x0(%esi,1),%esi
0x0210e9a0 <do_sys_vm86+320>:   push   %esi
0x0210e9a1 <do_sys_vm86+321>:   call   0x210e5b0 <mark_screen_rdonly>
0x0210e9a6 <do_sys_vm86+326>:   pop    %eax
0x0210e9a7 <do_sys_vm86+327>:   jmp    0x210e97a <do_sys_vm86+282>
0x0210e9a9 <do_sys_vm86+329>:   call   0x21222d0 <preempt_schedule>
0x0210e9ae <do_sys_vm86+334>:   jmp    0x210e96b <do_sys_vm86+267>
0x0210e9b0 <do_sys_vm86+336>:   mov    0x24(%edx),%ax
0x0210e9b4 <do_sys_vm86+340>:   mov    %ax,0x10(%ecx)
0x0210e9b8 <do_sys_vm86+344>:   mov    $0x174,%ecx
0x0210e9bd <do_sys_vm86+349>:   mov    0x24(%edx),%eax
0x0210e9c0 <do_sys_vm86+352>:   xor    %edx,%edx
0x0210e9c2 <do_sys_vm86+354>:   wrmsr
0x0210e9c4 <do_sys_vm86+356>:   jmp    0x210e95c <do_sys_vm86+252>
0x0210e9c6 <do_sys_vm86+358>:   movl   $0x0,0x5bc(%esi)
0x0210e9d0 <do_sys_vm86+368>:   jmp    0x210e8d8 <do_sys_vm86+120>
0x0210e9d5 <do_sys_vm86+373>:   cmp    $0x4,%eax
0x0210e9d8 <do_sys_vm86+376>:   jne    0x210e8ce <do_sys_vm86+110>
0x0210e9de <do_sys_vm86+382>:   movl   $0x47000,0x5bc(%esi)
0x0210e9e8 <do_sys_vm86+392>:   jmp    0x210e8d8 <do_sys_vm86+120>
0x0210e9ed <do_sys_vm86+397>:   lea    0x0(%esi),%esi
0x0210e9f0 <do_sys_vm86+400>:   movl   $0x7000,0x5bc(%esi)
0x0210e9fa <do_sys_vm86+410>:   jmp    0x210e8d8 <do_sys_vm86+120>

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Mon, 17 Nov 2003, Zwane Mwaikambo wrote:

> On Mon, 17 Nov 2003, Linus Torvalds wrote:
> 
> > What's the generated assembly language for this function with and without 
> > the "fix"?
> > 
> > If adding that printk fixes a triple fault, the issue is not likely to be 
> > the printk itself as much as the difference in code that the compiler 
> > generates - stack frame, memory re-ordering etc...
> 
> This would be my 'trusty' gcc 3.2.2 from RedHat 9
> (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

A little bird told me to send diffs... But there is a lot of noise due to 
offsets i'm afraid.

--- buggy	2003-11-17 18:09:35.302964248 -0500
+++ works	2003-11-17 18:09:47.744072912 -0500
@@ -21,11 +21,11 @@
 0x0210e8aa <do_sys_vm86+74>:    or     $0x20000,%edx
 0x0210e8b0 <do_sys_vm86+80>:    cmp    $0x3,%eax
 0x0210e8b3 <do_sys_vm86+83>:    mov    %edx,0x30(%edi)
-0x0210e8b6 <do_sys_vm86+86>:    je     0x210e9e0 <do_sys_vm86+384>
+0x0210e8b6 <do_sys_vm86+86>:    je     0x210e9f0 <do_sys_vm86+400>
 0x0210e8bc <do_sys_vm86+92>:    cmp    $0x3,%eax
-0x0210e8bf <do_sys_vm86+95>:    ja     0x210e9c5 <do_sys_vm86+357>
+0x0210e8bf <do_sys_vm86+95>:    ja     0x210e9d5 <do_sys_vm86+373>
 0x0210e8c5 <do_sys_vm86+101>:   cmp    $0x2,%eax
-0x0210e8c8 <do_sys_vm86+104>:   je     0x210e9b6 <do_sys_vm86+342>
+0x0210e8c8 <do_sys_vm86+104>:   je     0x210e9c6 <do_sys_vm86+358>
 0x0210e8ce <do_sys_vm86+110>:   movl   $0x247000,0x5bc(%esi)
 0x0210e8d8 <do_sys_vm86+120>:   mov    0xbc(%edi),%eax
 0x0210e8de <do_sys_vm86+126>:   movl   $0x0,0x18(%eax)
@@ -57,47 +57,52 @@
 0x0210e94e <do_sys_vm86+238>:   mov    0x10(%ecx),%ax
 0x0210e952 <do_sys_vm86+242>:   and    $0xffff,%eax
 0x0210e957 <do_sys_vm86+247>:   cmp    0x24(%edx),%eax
-0x0210e95a <do_sys_vm86+250>:   jne    0x210e9a0 <do_sys_vm86+320>
+0x0210e95a <do_sys_vm86+250>:   jne    0x210e9b0 <do_sys_vm86+336>
 0x0210e95c <do_sys_vm86+252>:   mov    0x14(%ebx),%eax
 0x0210e95f <do_sys_vm86+255>:   dec    %eax
 0x0210e960 <do_sys_vm86+256>:   mov    %eax,0x14(%ebx)
 0x0210e963 <do_sys_vm86+259>:   mov    0x8(%ebx),%eax
 0x0210e966 <do_sys_vm86+262>:   and    $0x8,%eax
-0x0210e969 <do_sys_vm86+265>:   jne    0x210e999 <do_sys_vm86+313>
-0x0210e96b <do_sys_vm86+267>:   mov    0x50(%edi),%eax
-0x0210e96e <do_sys_vm86+270>:   mov    %eax,0x5b4(%esi)
-0x0210e974 <do_sys_vm86+276>:   testb  $0x1,0x4c(%edi)
-0x0210e978 <do_sys_vm86+280>:   jne    0x210e990 <do_sys_vm86+304>
-0x0210e97a <do_sys_vm86+282>:   mov    0x4(%esi),%edx
-0x0210e97d <do_sys_vm86+285>:   xor    %eax,%eax
-0x0210e97f <do_sys_vm86+287>:   mov    %eax,%fs
-0x0210e981 <do_sys_vm86+289>:   mov    %eax,%gs
-0x0210e983 <do_sys_vm86+291>:   mov    %edi,%esp
-0x0210e985 <do_sys_vm86+293>:   mov    %edx,%ebp
-0x0210e987 <do_sys_vm86+295>:   jmp    0xfffeb100 <resume_userspace>
-0x0210e98c <do_sys_vm86+300>:   pop    %ebx
-0x0210e98d <do_sys_vm86+301>:   pop    %esi
-0x0210e98e <do_sys_vm86+302>:   pop    %edi
-0x0210e98f <do_sys_vm86+303>:   ret
-0x0210e990 <do_sys_vm86+304>:   push   %esi
-0x0210e991 <do_sys_vm86+305>:   call   0x210e5b0 <mark_screen_rdonly>
-0x0210e996 <do_sys_vm86+310>:   pop    %eax
-0x0210e997 <do_sys_vm86+311>:   jmp    0x210e97a <do_sys_vm86+282>
-0x0210e999 <do_sys_vm86+313>:   call   0x21222c0 <preempt_schedule>
-0x0210e99e <do_sys_vm86+318>:   jmp    0x210e96b <do_sys_vm86+267>
-0x0210e9a0 <do_sys_vm86+320>:   mov    0x24(%edx),%ax
-0x0210e9a4 <do_sys_vm86+324>:   mov    %ax,0x10(%ecx)
-0x0210e9a8 <do_sys_vm86+328>:   mov    $0x174,%ecx
-0x0210e9ad <do_sys_vm86+333>:   mov    0x24(%edx),%eax
-0x0210e9b0 <do_sys_vm86+336>:   xor    %edx,%edx
-0x0210e9b2 <do_sys_vm86+338>:   wrmsr
-0x0210e9b4 <do_sys_vm86+340>:   jmp    0x210e95c <do_sys_vm86+252>
-0x0210e9b6 <do_sys_vm86+342>:   movl   $0x0,0x5bc(%esi)
-0x0210e9c0 <do_sys_vm86+352>:   jmp    0x210e8d8 <do_sys_vm86+120>
-0x0210e9c5 <do_sys_vm86+357>:   cmp    $0x4,%eax
-0x0210e9c8 <do_sys_vm86+360>:   jne    0x210e8ce <do_sys_vm86+110>
-0x0210e9ce <do_sys_vm86+366>:   movl   $0x47000,0x5bc(%esi)
-0x0210e9d8 <do_sys_vm86+376>:   jmp    0x210e8d8 <do_sys_vm86+120>
-0x0210e9dd <do_sys_vm86+381>:   lea    0x0(%esi),%esi
-0x0210e9e0 <do_sys_vm86+384>:   movl   $0x7000,0x5bc(%esi)
-0x0210e9ea <do_sys_vm86+394>:   jmp    0x210e8d8 <do_sys_vm86+120>
+0x0210e969 <do_sys_vm86+265>:   jne    0x210e9a9 <do_sys_vm86+329>
+0x0210e96b <do_sys_vm86+267>:   push   $0x255f121
+0x0210e970 <do_sys_vm86+272>:   call   0x21285a0 <printk>
+0x0210e975 <do_sys_vm86+277>:   mov    0x50(%edi),%eax
+0x0210e978 <do_sys_vm86+280>:   mov    %eax,0x5b4(%esi)
+0x0210e97e <do_sys_vm86+286>:   pop    %eax
+0x0210e97f <do_sys_vm86+287>:   testb  $0x1,0x4c(%edi)
+0x0210e983 <do_sys_vm86+291>:   jne    0x210e9a0 <do_sys_vm86+320>
+0x0210e985 <do_sys_vm86+293>:   mov    0x4(%esi),%edx
+0x0210e988 <do_sys_vm86+296>:   xor    %eax,%eax
+0x0210e98a <do_sys_vm86+298>:   mov    %eax,%fs
+0x0210e98c <do_sys_vm86+300>:   mov    %eax,%gs
+0x0210e98e <do_sys_vm86+302>:   mov    %edi,%esp
+0x0210e990 <do_sys_vm86+304>:   mov    %edx,%ebp
+0x0210e992 <do_sys_vm86+306>:   jmp    0xfffeb100 <resume_userspace>
+0x0210e997 <do_sys_vm86+311>:   pop    %ebx
+0x0210e998 <do_sys_vm86+312>:   pop    %esi
+0x0210e999 <do_sys_vm86+313>:   pop    %edi
+0x0210e99a <do_sys_vm86+314>:   ret
+0x0210e99b <do_sys_vm86+315>:   nop
+0x0210e99c <do_sys_vm86+316>:   lea    0x0(%esi,1),%esi
+0x0210e9a0 <do_sys_vm86+320>:   push   %esi
+0x0210e9a1 <do_sys_vm86+321>:   call   0x210e5b0 <mark_screen_rdonly>
+0x0210e9a6 <do_sys_vm86+326>:   pop    %eax
+0x0210e9a7 <do_sys_vm86+327>:   jmp    0x210e985 <do_sys_vm86+293>
+0x0210e9a9 <do_sys_vm86+329>:   call   0x21222d0 <preempt_schedule>
+0x0210e9ae <do_sys_vm86+334>:   jmp    0x210e96b <do_sys_vm86+267>
+0x0210e9b0 <do_sys_vm86+336>:   mov    0x24(%edx),%ax
+0x0210e9b4 <do_sys_vm86+340>:   mov    %ax,0x10(%ecx)
+0x0210e9b8 <do_sys_vm86+344>:   mov    $0x174,%ecx
+0x0210e9bd <do_sys_vm86+349>:   mov    0x24(%edx),%eax
+0x0210e9c0 <do_sys_vm86+352>:   xor    %edx,%edx
+0x0210e9c2 <do_sys_vm86+354>:   wrmsr
+0x0210e9c4 <do_sys_vm86+356>:   jmp    0x210e95c <do_sys_vm86+252>
+0x0210e9c6 <do_sys_vm86+358>:   movl   $0x0,0x5bc(%esi)
+0x0210e9d0 <do_sys_vm86+368>:   jmp    0x210e8d8 <do_sys_vm86+120>
+0x0210e9d5 <do_sys_vm86+373>:   cmp    $0x4,%eax
+0x0210e9d8 <do_sys_vm86+376>:   jne    0x210e8ce <do_sys_vm86+110>
+0x0210e9de <do_sys_vm86+382>:   movl   $0x47000,0x5bc(%esi)
+0x0210e9e8 <do_sys_vm86+392>:   jmp    0x210e8d8 <do_sys_vm86+120>
+0x0210e9ed <do_sys_vm86+397>:   lea    0x0(%esi),%esi
+0x0210e9f0 <do_sys_vm86+400>:   movl   $0x7000,0x5bc(%esi)
+0x0210e9fa <do_sys_vm86+410>:   jmp    0x210e8d8 <do_sys_vm86+120>

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Mon, 17 Nov 2003, Linus Torvalds wrote:

> What's the generated assembly language for this function with and without 
> the "fix"?
> 
> If adding that printk fixes a triple fault, the issue is not likely to be 
> the printk itself as much as the difference in code that the compiler 
> generates - stack frame, memory re-ordering etc...

This would be my 'trusty' gcc 3.2.2 from RedHat 9
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

With the fix:
0x0210e860 <do_sys_vm86+0>:     push   %edi
0x0210e861 <do_sys_vm86+1>:     mov    $0xffffe000,%eax
0x0210e866 <do_sys_vm86+6>:     push   %esi
0x0210e867 <do_sys_vm86+7>:     and    %esp,%eax
0x0210e869 <do_sys_vm86+9>:     push   %ebx
0x0210e86a <do_sys_vm86+10>:    mov    0x10(%esp,1),%edi
0x0210e86e <do_sys_vm86+14>:    mov    0x14(%esp,1),%esi
0x0210e872 <do_sys_vm86+18>:    movl   $0x0,0x1c(%edi)
0x0210e879 <do_sys_vm86+25>:    movl   $0x0,0x20(%edi)
0x0210e880 <do_sys_vm86+32>:    mov    (%eax),%edx
0x0210e882 <do_sys_vm86+34>:    mov    0x30(%edi),%eax
0x0210e885 <do_sys_vm86+37>:    mov    %eax,0x5b8(%edx)
0x0210e88b <do_sys_vm86+43>:    mov    0x30(%edi),%edx
0x0210e88e <do_sys_vm86+46>:    mov    0xbc(%edi),%eax
0x0210e894 <do_sys_vm86+52>:    and    $0xdd5,%edx
0x0210e89a <do_sys_vm86+58>:    mov    %edx,0x30(%edi)
0x0210e89d <do_sys_vm86+61>:    mov    0x30(%eax),%eax
0x0210e8a0 <do_sys_vm86+64>:    and    $0xfffff22a,%eax
0x0210e8a5 <do_sys_vm86+69>:    or     %eax,%edx
0x0210e8a7 <do_sys_vm86+71>:    mov    0x54(%edi),%eax
0x0210e8aa <do_sys_vm86+74>:    or     $0x20000,%edx
0x0210e8b0 <do_sys_vm86+80>:    cmp    $0x3,%eax
0x0210e8b3 <do_sys_vm86+83>:    mov    %edx,0x30(%edi)
0x0210e8b6 <do_sys_vm86+86>:    je     0x210e9f0 <do_sys_vm86+400>
0x0210e8bc <do_sys_vm86+92>:    cmp    $0x3,%eax
0x0210e8bf <do_sys_vm86+95>:    ja     0x210e9d5 <do_sys_vm86+373>
0x0210e8c5 <do_sys_vm86+101>:   cmp    $0x2,%eax
0x0210e8c8 <do_sys_vm86+104>:   je     0x210e9c6 <do_sys_vm86+358>
0x0210e8ce <do_sys_vm86+110>:   movl   $0x247000,0x5bc(%esi)
0x0210e8d8 <do_sys_vm86+120>:   mov    0xbc(%edi),%eax
0x0210e8de <do_sys_vm86+126>:   movl   $0x0,0x18(%eax)
0x0210e8e5 <do_sys_vm86+133>:   mov    0x360(%esi),%eax
0x0210e8eb <do_sys_vm86+139>:   mov    %eax,0x5c0(%esi)
0x0210e8f1 <do_sys_vm86+145>:   movl   %fs,0x5c4(%esi)
0x0210e8f7 <do_sys_vm86+151>:   movl   %gs,0x5c8(%esi)
0x0210e8fd <do_sys_vm86+157>:   mov    $0xffffe000,%ebx
0x0210e902 <do_sys_vm86+162>:   and    %esp,%ebx
0x0210e904 <do_sys_vm86+164>:   mov    0x14(%ebx),%eax
0x0210e907 <do_sys_vm86+167>:   inc    %eax
0x0210e908 <do_sys_vm86+168>:   mov    %eax,0x14(%ebx)
0x0210e90b <do_sys_vm86+171>:   mov    0x10(%ebx),%eax
0x0210e90e <do_sys_vm86+174>:   mov    0x4(%esi),%edx
0x0210e911 <do_sys_vm86+177>:   shl    $0x9,%eax
0x0210e914 <do_sys_vm86+180>:   lea    0x26ff000(%eax),%ecx
0x0210e91a <do_sys_vm86+186>:   lea    0x4c(%edi),%eax
0x0210e91d <do_sys_vm86+189>:   mov    %eax,0x360(%esi)
0x0210e923 <do_sys_vm86+195>:   sub    0x1c(%edx),%eax
0x0210e926 <do_sys_vm86+198>:   add    0x20(%edx),%eax
0x0210e929 <do_sys_vm86+201>:   mov    %eax,0x4(%ecx)
0x0210e92c <do_sys_vm86+204>:   mov    0x25fe52c,%eax
0x0210e931 <do_sys_vm86+209>:   test   $0x800,%eax
0x0210e936 <do_sys_vm86+214>:   je     0x210e942 <do_sys_vm86+226>
0x0210e938 <do_sys_vm86+216>:   movl   $0x0,0x364(%esi)
0x0210e942 <do_sys_vm86+226>:   lea    0x340(%esi),%edx
0x0210e948 <do_sys_vm86+232>:   mov    0x20(%edx),%eax
0x0210e94b <do_sys_vm86+235>:   mov    %eax,0x4(%ecx)
0x0210e94e <do_sys_vm86+238>:   mov    0x10(%ecx),%ax
0x0210e952 <do_sys_vm86+242>:   and    $0xffff,%eax
0x0210e957 <do_sys_vm86+247>:   cmp    0x24(%edx),%eax
0x0210e95a <do_sys_vm86+250>:   jne    0x210e9b0 <do_sys_vm86+336>
0x0210e95c <do_sys_vm86+252>:   mov    0x14(%ebx),%eax
0x0210e95f <do_sys_vm86+255>:   dec    %eax
0x0210e960 <do_sys_vm86+256>:   mov    %eax,0x14(%ebx)
0x0210e963 <do_sys_vm86+259>:   mov    0x8(%ebx),%eax
0x0210e966 <do_sys_vm86+262>:   and    $0x8,%eax
0x0210e969 <do_sys_vm86+265>:   jne    0x210e9a9 <do_sys_vm86+329>
0x0210e96b <do_sys_vm86+267>:   push   $0x255f121
0x0210e970 <do_sys_vm86+272>:   call   0x21285a0 <printk>
0x0210e975 <do_sys_vm86+277>:   mov    0x50(%edi),%eax
0x0210e978 <do_sys_vm86+280>:   mov    %eax,0x5b4(%esi)
0x0210e97e <do_sys_vm86+286>:   pop    %eax
0x0210e97f <do_sys_vm86+287>:   testb  $0x1,0x4c(%edi)
0x0210e983 <do_sys_vm86+291>:   jne    0x210e9a0 <do_sys_vm86+320>
0x0210e985 <do_sys_vm86+293>:   mov    0x4(%esi),%edx
0x0210e988 <do_sys_vm86+296>:   xor    %eax,%eax
0x0210e98a <do_sys_vm86+298>:   mov    %eax,%fs
0x0210e98c <do_sys_vm86+300>:   mov    %eax,%gs
0x0210e98e <do_sys_vm86+302>:   mov    %edi,%esp
0x0210e990 <do_sys_vm86+304>:   mov    %edx,%ebp
0x0210e992 <do_sys_vm86+306>:   jmp    0xfffeb100 <resume_userspace>
0x0210e997 <do_sys_vm86+311>:   pop    %ebx
0x0210e998 <do_sys_vm86+312>:   pop    %esi
0x0210e999 <do_sys_vm86+313>:   pop    %edi
0x0210e99a <do_sys_vm86+314>:   ret
0x0210e99b <do_sys_vm86+315>:   nop
0x0210e99c <do_sys_vm86+316>:   lea    0x0(%esi,1),%esi
0x0210e9a0 <do_sys_vm86+320>:   push   %esi
0x0210e9a1 <do_sys_vm86+321>:   call   0x210e5b0 <mark_screen_rdonly>
0x0210e9a6 <do_sys_vm86+326>:   pop    %eax
0x0210e9a7 <do_sys_vm86+327>:   jmp    0x210e985 <do_sys_vm86+293>
0x0210e9a9 <do_sys_vm86+329>:   call   0x21222d0 <preempt_schedule>
0x0210e9ae <do_sys_vm86+334>:   jmp    0x210e96b <do_sys_vm86+267>
0x0210e9b0 <do_sys_vm86+336>:   mov    0x24(%edx),%ax
0x0210e9b4 <do_sys_vm86+340>:   mov    %ax,0x10(%ecx)
0x0210e9b8 <do_sys_vm86+344>:   mov    $0x174,%ecx
0x0210e9bd <do_sys_vm86+349>:   mov    0x24(%edx),%eax
0x0210e9c0 <do_sys_vm86+352>:   xor    %edx,%edx
0x0210e9c2 <do_sys_vm86+354>:   wrmsr
0x0210e9c4 <do_sys_vm86+356>:   jmp    0x210e95c <do_sys_vm86+252>
0x0210e9c6 <do_sys_vm86+358>:   movl   $0x0,0x5bc(%esi)
0x0210e9d0 <do_sys_vm86+368>:   jmp    0x210e8d8 <do_sys_vm86+120>
0x0210e9d5 <do_sys_vm86+373>:   cmp    $0x4,%eax
0x0210e9d8 <do_sys_vm86+376>:   jne    0x210e8ce <do_sys_vm86+110>
0x0210e9de <do_sys_vm86+382>:   movl   $0x47000,0x5bc(%esi)
0x0210e9e8 <do_sys_vm86+392>:   jmp    0x210e8d8 <do_sys_vm86+120>
0x0210e9ed <do_sys_vm86+397>:   lea    0x0(%esi),%esi
0x0210e9f0 <do_sys_vm86+400>:   movl   $0x7000,0x5bc(%esi)
0x0210e9fa <do_sys_vm86+410>:   jmp    0x210e8d8 <do_sys_vm86+120>

Without the fix:
0x0210e860 <do_sys_vm86+0>:     push   %edi
0x0210e861 <do_sys_vm86+1>:     mov    $0xffffe000,%eax
0x0210e866 <do_sys_vm86+6>:     push   %esi
0x0210e867 <do_sys_vm86+7>:     and    %esp,%eax
0x0210e869 <do_sys_vm86+9>:     push   %ebx
0x0210e86a <do_sys_vm86+10>:    mov    0x10(%esp,1),%edi
0x0210e86e <do_sys_vm86+14>:    mov    0x14(%esp,1),%esi
0x0210e872 <do_sys_vm86+18>:    movl   $0x0,0x1c(%edi)
0x0210e879 <do_sys_vm86+25>:    movl   $0x0,0x20(%edi)
0x0210e880 <do_sys_vm86+32>:    mov    (%eax),%edx
0x0210e882 <do_sys_vm86+34>:    mov    0x30(%edi),%eax
0x0210e885 <do_sys_vm86+37>:    mov    %eax,0x5b8(%edx)
0x0210e88b <do_sys_vm86+43>:    mov    0x30(%edi),%edx
0x0210e88e <do_sys_vm86+46>:    mov    0xbc(%edi),%eax
0x0210e894 <do_sys_vm86+52>:    and    $0xdd5,%edx
0x0210e89a <do_sys_vm86+58>:    mov    %edx,0x30(%edi)
0x0210e89d <do_sys_vm86+61>:    mov    0x30(%eax),%eax
0x0210e8a0 <do_sys_vm86+64>:    and    $0xfffff22a,%eax
0x0210e8a5 <do_sys_vm86+69>:    or     %eax,%edx
0x0210e8a7 <do_sys_vm86+71>:    mov    0x54(%edi),%eax
0x0210e8aa <do_sys_vm86+74>:    or     $0x20000,%edx
0x0210e8b0 <do_sys_vm86+80>:    cmp    $0x3,%eax
0x0210e8b3 <do_sys_vm86+83>:    mov    %edx,0x30(%edi)
0x0210e8b6 <do_sys_vm86+86>:    je     0x210e9e0 <do_sys_vm86+384>
0x0210e8bc <do_sys_vm86+92>:    cmp    $0x3,%eax
0x0210e8bf <do_sys_vm86+95>:    ja     0x210e9c5 <do_sys_vm86+357>
0x0210e8c5 <do_sys_vm86+101>:   cmp    $0x2,%eax
0x0210e8c8 <do_sys_vm86+104>:   je     0x210e9b6 <do_sys_vm86+342>
0x0210e8ce <do_sys_vm86+110>:   movl   $0x247000,0x5bc(%esi)
0x0210e8d8 <do_sys_vm86+120>:   mov    0xbc(%edi),%eax
0x0210e8de <do_sys_vm86+126>:   movl   $0x0,0x18(%eax)
0x0210e8e5 <do_sys_vm86+133>:   mov    0x360(%esi),%eax
0x0210e8eb <do_sys_vm86+139>:   mov    %eax,0x5c0(%esi)
0x0210e8f1 <do_sys_vm86+145>:   movl   %fs,0x5c4(%esi)
0x0210e8f7 <do_sys_vm86+151>:   movl   %gs,0x5c8(%esi)
0x0210e8fd <do_sys_vm86+157>:   mov    $0xffffe000,%ebx
0x0210e902 <do_sys_vm86+162>:   and    %esp,%ebx
0x0210e904 <do_sys_vm86+164>:   mov    0x14(%ebx),%eax
0x0210e907 <do_sys_vm86+167>:   inc    %eax
0x0210e908 <do_sys_vm86+168>:   mov    %eax,0x14(%ebx)
0x0210e90b <do_sys_vm86+171>:   mov    0x10(%ebx),%eax
0x0210e90e <do_sys_vm86+174>:   mov    0x4(%esi),%edx
0x0210e911 <do_sys_vm86+177>:   shl    $0x9,%eax
0x0210e914 <do_sys_vm86+180>:   lea    0x26ff000(%eax),%ecx
0x0210e91a <do_sys_vm86+186>:   lea    0x4c(%edi),%eax
0x0210e91d <do_sys_vm86+189>:   mov    %eax,0x360(%esi)
0x0210e923 <do_sys_vm86+195>:   sub    0x1c(%edx),%eax
0x0210e926 <do_sys_vm86+198>:   add    0x20(%edx),%eax
0x0210e929 <do_sys_vm86+201>:   mov    %eax,0x4(%ecx)
0x0210e92c <do_sys_vm86+204>:   mov    0x25fe52c,%eax
0x0210e931 <do_sys_vm86+209>:   test   $0x800,%eax
0x0210e936 <do_sys_vm86+214>:   je     0x210e942 <do_sys_vm86+226>
0x0210e938 <do_sys_vm86+216>:   movl   $0x0,0x364(%esi)
0x0210e942 <do_sys_vm86+226>:   lea    0x340(%esi),%edx
0x0210e948 <do_sys_vm86+232>:   mov    0x20(%edx),%eax
0x0210e94b <do_sys_vm86+235>:   mov    %eax,0x4(%ecx)
0x0210e94e <do_sys_vm86+238>:   mov    0x10(%ecx),%ax
0x0210e952 <do_sys_vm86+242>:   and    $0xffff,%eax
0x0210e957 <do_sys_vm86+247>:   cmp    0x24(%edx),%eax
0x0210e95a <do_sys_vm86+250>:   jne    0x210e9a0 <do_sys_vm86+320>
0x0210e95c <do_sys_vm86+252>:   mov    0x14(%ebx),%eax
0x0210e95f <do_sys_vm86+255>:   dec    %eax
0x0210e960 <do_sys_vm86+256>:   mov    %eax,0x14(%ebx)
0x0210e963 <do_sys_vm86+259>:   mov    0x8(%ebx),%eax
0x0210e966 <do_sys_vm86+262>:   and    $0x8,%eax
0x0210e969 <do_sys_vm86+265>:   jne    0x210e999 <do_sys_vm86+313>
0x0210e96b <do_sys_vm86+267>:   mov    0x50(%edi),%eax
0x0210e96e <do_sys_vm86+270>:   mov    %eax,0x5b4(%esi)
0x0210e974 <do_sys_vm86+276>:   testb  $0x1,0x4c(%edi)
0x0210e978 <do_sys_vm86+280>:   jne    0x210e990 <do_sys_vm86+304>
0x0210e97a <do_sys_vm86+282>:   mov    0x4(%esi),%edx
0x0210e97d <do_sys_vm86+285>:   xor    %eax,%eax
0x0210e97f <do_sys_vm86+287>:   mov    %eax,%fs
0x0210e981 <do_sys_vm86+289>:   mov    %eax,%gs
0x0210e983 <do_sys_vm86+291>:   mov    %edi,%esp
0x0210e985 <do_sys_vm86+293>:   mov    %edx,%ebp
0x0210e987 <do_sys_vm86+295>:   jmp    0xfffeb100 <resume_userspace>
0x0210e98c <do_sys_vm86+300>:   pop    %ebx
0x0210e98d <do_sys_vm86+301>:   pop    %esi
0x0210e98e <do_sys_vm86+302>:   pop    %edi
0x0210e98f <do_sys_vm86+303>:   ret
0x0210e990 <do_sys_vm86+304>:   push   %esi
0x0210e991 <do_sys_vm86+305>:   call   0x210e5b0 <mark_screen_rdonly>
0x0210e996 <do_sys_vm86+310>:   pop    %eax
0x0210e997 <do_sys_vm86+311>:   jmp    0x210e97a <do_sys_vm86+282>
0x0210e999 <do_sys_vm86+313>:   call   0x21222c0 <preempt_schedule>
0x0210e99e <do_sys_vm86+318>:   jmp    0x210e96b <do_sys_vm86+267>
0x0210e9a0 <do_sys_vm86+320>:   mov    0x24(%edx),%ax
0x0210e9a4 <do_sys_vm86+324>:   mov    %ax,0x10(%ecx)
0x0210e9a8 <do_sys_vm86+328>:   mov    $0x174,%ecx
0x0210e9ad <do_sys_vm86+333>:   mov    0x24(%edx),%eax
0x0210e9b0 <do_sys_vm86+336>:   xor    %edx,%edx
0x0210e9b2 <do_sys_vm86+338>:   wrmsr
0x0210e9b4 <do_sys_vm86+340>:   jmp    0x210e95c <do_sys_vm86+252>
0x0210e9b6 <do_sys_vm86+342>:   movl   $0x0,0x5bc(%esi)
0x0210e9c0 <do_sys_vm86+352>:   jmp    0x210e8d8 <do_sys_vm86+120>
0x0210e9c5 <do_sys_vm86+357>:   cmp    $0x4,%eax
0x0210e9c8 <do_sys_vm86+360>:   jne    0x210e8ce <do_sys_vm86+110>
0x0210e9ce <do_sys_vm86+366>:   movl   $0x47000,0x5bc(%esi)
0x0210e9d8 <do_sys_vm86+376>:   jmp    0x210e8d8 <do_sys_vm86+120>
0x0210e9dd <do_sys_vm86+381>:   lea    0x0(%esi),%esi
0x0210e9e0 <do_sys_vm86+384>:   movl   $0x7000,0x5bc(%esi)
0x0210e9ea <do_sys_vm86+394>:   jmp    0x210e8d8 <do_sys_vm86+120>

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Linus Torvalds]

On Mon, 17 Nov 2003, Zwane Mwaikambo wrote:
> 
> I've managed to `fix` the triple fault (see further below for the patch 
> in all it's glory).

What's the generated assembly language for this function with and without 
the "fix"?

If adding that printk fixes a triple fault, the issue is not likely to be 
the printk itself as much as the difference in code that the compiler 
generates - stack frame, memory re-ordering etc...

		Linus

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Sat, 15 Nov 2003, Zwane Mwaikambo wrote:

> The 4G/4G page fault handling path doesn't appear to handle faults 
> happening whilst in vm86. The regs->xcs != __USER_CS so it confused the in 
> kernel test.
> 
> However i'm still debugging the X11 triple fault in test9-mm3

I've managed to `fix` the triple fault (see further below for the patch 
in all it's glory). Unfortunately i have been unable to come up with a 
simpler workaround which is fewer instructions and easier to debug. I have 
tried the following;

mb()/barrier()
flush_tlb_all()
wbinvd()
outb(0x80,0x00)
local_irq_save(flags); local_irq_enable(); loop(); local_irq_restore(flags);
long_loop()

What i do know is that in the following code;

	__asm__ __volatile__(
		"xorl %%eax,%%eax; movl %%eax,%%fs; movl %%eax,%%gs\n\t"
		"movl %0,%%esp\n\t"
		"movl %1,%%ebp\n\t"
		"jmp resume_userspace"
		: /* no outputs */
		:"r" (&info->regs), "r" (tsk->thread_info) : "ax");

It does get to resume_userspace as putting a $0 into %ebp will oops in 
__switch_to

And here is the current 'workaround'. Any hints?

Index: arch/i386/kernel/vm86.c
===================================================================
RCS file: /build/cvsroot/linux-2.6.0-test9-mm3/arch/i386/kernel/vm86.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 vm86.c
--- arch/i386/kernel/vm86.c	13 Nov 2003 08:07:17 -0000	1.1.1.1
+++ arch/i386/kernel/vm86.c	17 Nov 2003 21:45:13 -0000
@@ -312,6 +311,8 @@ static void do_sys_vm86(struct kernel_vm
 	tsk->thread.screen_bitmap = info->screen_bitmap;
 	if (info->flags & VM86_SCREEN_BITMAP)
 		mark_screen_rdonly(tsk);
+
+	printk("ooh la la\n");
 	__asm__ __volatile__(
 		"xorl %%eax,%%eax; movl %%eax,%%fs; movl %%eax,%%gs\n\t"
 		"movl %0,%%esp\n\t"

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Sat, 15 Nov 2003, Zwane Mwaikambo wrote:

> The 4G/4G page fault handling path doesn't appear to handle faults 
> happening whilst in vm86. The regs->xcs != __USER_CS so it confused the in 
> kernel test.

Perhaps this would be more desirable?

Index: linux-2.6.0-test9-mm3/arch/i386/mm/fault.c
===================================================================
RCS file: /build/cvsroot/linux-2.6.0-test9-mm3/arch/i386/mm/fault.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 fault.c
--- linux-2.6.0-test9-mm3/arch/i386/mm/fault.c	13 Nov 2003 08:07:17 -0000	1.1.1.1
+++ linux-2.6.0-test9-mm3/arch/i386/mm/fault.c	15 Nov 2003 19:40:17 -0000
@@ -264,7 +264,9 @@ asmlinkage void do_page_fault(struct pt_
 		if (error_code & 3)
 			goto bad_area_nosemaphore;
 
- 		goto vmalloc_fault;
+		/* If it's vm86 fall through */
+		if (!(regs->eflags & VM_MASK))
+			goto vmalloc_fault;
 	}
 #else
 	if (unlikely(address >= TASK_SIZE)) { 

[PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

The 4G/4G page fault handling path doesn't appear to handle faults 
happening whilst in vm86. The regs->xcs != __USER_CS so it confused the in 
kernel test.

However i'm still debugging the X11 triple fault in test9-mm3

Unable to handle kernel paging request at virtual address 00002000
 printing eip:
00007341
*pde = 00000000
Oops: 0004 [#1]
SMP DEBUG_PAGEALLOC
CPU:    0
EIP:    c000:[<00007341>]    Not tainted VLI
EFLAGS: 00033246
EIP is at 0x7341
eax: 32454256   ebx: 00000000   ecx: 00000000   edx: 00000000
esi: 00000000   edi: 00002000   ebp: 00000fd6   esp: 087bbf24
ds: 0000   es: 0000   ss: 0068
Process X (pid: 939, threadinfo=087ba000 task=0891c690)
Stack: 00000fcb 00000100 00000000 0000c000 00000000 00000000 00000000 00000000
       00000005 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
       ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Call Trace:

Index: linux-2.6.0-test9-mm3/arch/i386/mm/fault.c
===================================================================
RCS file: /build/cvsroot/linux-2.6.0-test9-mm3/arch/i386/mm/fault.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 fault.c
--- linux-2.6.0-test9-mm3/arch/i386/mm/fault.c	13 Nov 2003 08:07:17 -0000	1.1.1.1
+++ linux-2.6.0-test9-mm3/arch/i386/mm/fault.c	15 Nov 2003 19:08:34 -0000
@@ -264,7 +264,9 @@ asmlinkage void do_page_fault(struct pt_
 		if (error_code & 3)
 			goto bad_area_nosemaphore;
 
- 		goto vmalloc_fault;
+		/* If it's vm86 fall through */
+		if (!(error_code & 4))
+			goto vmalloc_fault;
 	}
 #else
 	if (unlikely(address >= TASK_SIZE)) {