Re: 2.6.12-rc2-mm3

[Borislav Petkov <petkov@uni-muenster.de>]

On Tuesday 12 April 2005 06:20, Stas Sergeev wrote:

Here we go again:

You might be right about the int3 instruction:

(gdb) disas 0xc0102ee0
Dump of assembler code for function restore_all:
0xc0102ed1 <restore_all+0>:     mov    0x30(%esp),%eax
0xc0102ed5 <restore_all+4>:     mov    0x2c(%esp),%al
0xc0102ed9 <restore_all+8>:     test   $0x20003,%eax
0xc0102ede <restore_all+13>:    je     0xc0102ee7 <resume_kernelX>
0xc0102ee0 <restore_all+15>:    cmpl   $0x0,0x14(%ebp)
0xc0102ee4 <restore_all+19>:    je     0xc0102ee7 <resume_kernelX>
0xc0102ee6 <restore_all+21>:    int3
End of assembler dump.

> Could you please also do
> "p $esp" or "info reg", so that we can
> see the rest of the registers?

Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0102ee7 in resume_kernelX () at atomic.h:175
175     {
(gdb) p $esp
$1 = (void *) 0xdfcb4fc4

(gdb) info reg
eax            0x273    627
ecx            0x0      0
edx            0x10000  65536
ebx            0xb7fd9c00       -1208116224
esp            0xdfcb4fc4       0xdfcb4fc4
ebp            0xbfbd5948       0xbfbd5948
esi            0x77     119
edi            0x1cb    459
eip            0xc0102ee7       0xc0102ee7
eflags         0x82     130
cs             0x60     96
ss             0x68     104
ds             0xc010007b       -1072693125
es             0xdfcb007b       -540344197
fs             0xffff   65535
gs             0xffff   65535
(gdb)
> >> And as we see, we're at the "mov    0x30(%esp),%eax" which accesses
> >> above the bottom of the stack.
>
> But that's strange. Another instance of
> the 0x30(%esp) is there a few instructions
> above this one, see it with "disas restore_all".
> It is much more likely that the real offender
> is the previous instruction. $eip points on
> the instruction *after* the trap, which might
> be innocent.
>
> >> After applying nmi_stack_correct-fix.patch, rc2-mm3
>
> I can't find this one in an -mm broken-outs.
> Where is this patch?
> Could you please also test this one:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
>
> > Interesting.  It could be an interaction between the kgdb patch and the
> > new vm86 checking code.
>
> I think so too, will have a look if I can
> reproduce it.
>
> > The above code is accessing esp+56,
>
> Yes, but this particular instruction was
> not reached. "int $3" killed the system
> for some reasons.
>
> > -	p->thread.esp0 = (unsigned long) (childregs+1) - 8;
> > +	p->thread.esp0 = (unsigned long) (childregs+1) - 15;
<snip>

So, as next I'm gonna try disabling CONFIG_TRAP_BAD_SYSCALL_EXITS and see what 
happens there and then the stack-aligned process.c one liner above.
/me open to testing suggestions.

Regards,
Boris.