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

["Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>]

On 07/04/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 7 Apr 2007 20:48:43 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > On 07/04/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > On Sat, 07 Apr 2007 20:09:43 +0200 Michal Piotrowski <michal.k.k.piotrowski@gmail.com> 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?

No, it wasn't. I'll retest with patch 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.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/