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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
