Re: mm snapshot broken-out-2007-04-07-03-27.tar.gz uploaded

[Andrew Morton]

On Sat, 7 Apr 2007 20:48:43 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@xxxxxxxxx> wrote:

> On 07/04/07, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Sat, 07 Apr 2007 20:09:43 +0200 Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> wrote:
> >
> > > BTW. I guess that this need a similar fix.
> > >
> > > kernel BUG at kernel/ptrace.c:494!
> > > invalid opcode: 0000 [#2]
> > > PREEMPT SMP
> > > last sysfs file: devices/platform/w83627hf.656/temp2_input
> > > Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss intel_agp snd_pcm agpgart evdev snd_timer snd soundcore i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
> > > CPU:    1
> > > EIP:    0060:[<c0163f22>]    Not tainted VLI
> > > EFLAGS: 00010202   (2.6.21-rc6-mm1 #1)
> > > EIP is at ptrace_exit+0x29/0x21d
> > >
> >
> > no, I don't see what would cause that.  Was there no call trace?
> 
> Here is a call trace (it was in the first email).
> 
> Call Trace:
>  [<c012820e>] do_exit+0x16b/0x86c
>  [<c0105a77>] die+0x206/0x22c
>  [<c0105b27>] do_trap+0x8a/0xa4
>  [<c0105e93>] do_invalid_op+0x88/0x92
>  [<c0351e89>] error_code+0x79/0x80
>  [<c0163566>] ptrace_do_wait+0x1eb/0x510
>  [<c0127e10>] do_wait+0x9d6/0xbad
>  [<c0128017>] sys_wait4+0x30/0x32
>  [<c0128040>] sys_waitpid+0x27/0x29
>  [<c010424c>] syscall_call+0x7/0xb
>  [<b7f36410>] 0xb7f36410

Was that with the earlier ptrace fix applied?

Because what could happen is that ptrace_do_wait() (or anything else)
goes BUG, then the trap handler ends up calling do_exit(), which calls
ptrace_exit() which will then go BUG again over non-zero preempt_count.

Asserting that preempt_count==0 on the do_exit() path is a bad idea, because
do_exit() is called on the oops path - we're virtually assured that we'll get
recursive crashes.

I think I'll just disable the whole NO_LOCKS thing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/