On 07/04/07, Andrew Morton <[email protected]> wrote:
On Sat, 7 Apr 2007 20:48:43 +0200 "Michal Piotrowski" <[email protected]> wrote:
> On 07/04/07, Andrew Morton <[email protected]> wrote:
> > On Sat, 07 Apr 2007 20:09:43 +0200 Michal Piotrowski <[email protected]> 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 [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]
