Re: Fwd: Reporting some Kernel Panics

On Fri, 2005-07-08 at 14:18 -0600, Timothy R. Chavez wrote: >These don't look familiar to me, but I think it'd be good to send them >out to everyone to take a look... > > HTML-ised, word-wrapped, 'deepSkyBlue' oopses? Can I have some of what you lot are smoking? :) The first panic is similar to something else I've seen but not managed to make any progress with. In that case I was told the precise kernel and was able to determine that the oops in proc_get_inode was due to an invalid ->owner field in try_module_get(). That one was sent to me as an OpenOffice document, but I'll do the world a favour and reproduce it here as text... Oops: 0000 [1] SMP inode=2 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 CPU 7 Modules linked in: michael_mic parport_pc lp parport netconsole netdump autofs4 i2c_dev i2c_core sunrpc ds yenta_socket pcmcia_core button battery ac md5 ipv6 ohci_hcd ehci_hcd tg3 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod aacraid sd_mod scsi_mod Pid: 10704, comm: mount_test Not tainted 2.6.9-11.EL.audit.74smp RIP: 0010:[<ffffffff801a6764>] <ffffffff801a6764>{proc_get_inode+199} RSP: 0018:0000010068eb9ce8 EFLAGS: 00010282 RAX: 0000000000000007 RBX: 000001007cce6d70 RCX: 0000000000000000 RDX: ffffffffa01a5180 RSI: 000001000314b478 RDI: ffffffff80476380 RBP: 0000010068a1e060 R08: 0000010068eb9ca8 R09: 0000000000000000 RBP: 0000010068a1e060 R08: 0000010068eb9ca8 R09: 0000000000000000 R10: 000001006d81c950 R11: 0000000000000058 R12: 000001007ff05538 R13: 0000000000000000 R14: 00000000ffffffea R15: 0000010068eb9d98 FS: 0000002a95583b00(0000) GS:ffffffff804c6f80(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffa01a5180 CR3: 000000007fe9a000 CR4: 00000000000006e0 Process mount_test (pid: 10704, threadinfo 0000010068eb8000, task 000001006c5be030) Stack: 000001007cce6d70 00000100679ed260 000001006963e600 ffffffff801a91da fffffffffffffff4 00000100679ed260 000001006963e600 00000100679ed368 0000010068eb9e58 ffffffff80182060 Call Trace: <ffffffff801a91da>{proc_lookup+246} <ffffffff80182060>{do_lookup+230} <ffffffff80182c76>{link_path_walk+2508} <ffffffff801832a7>{path_lookup+451} <ffffffff80183553>{__user_walk+47} <ffffffff8017e037>{vfs_lstat+21} <ffffffff80154234>{audit_syscall_entry+306} <ffffffff8017e369>{sys_newlstat+17} <ffffffff801141e4>{syscall_trace_enter+161} <ffffffff80110142>{tracesys+113} <ffffffff801101a2>{tracesys+209} Code: 83 3a 02 74 32 89 c0 48 c1 e0 07 48 8d 04 02 ff 80 00 01 00 RIP <ffffffff801a6764>{proc_get_inode+199} RSP <0000010068eb9ce8> CR2: ffffffffa01a5180 In this case, the owner field of the proc directory in question is set to 0xffffffffa01a5180, when it _should_ have been a pointer to a valid 'struct module'. We don't seem to have been given the faulting address in the panic you show, but I'm fairly sure it'll be the same thing. Can you tell me which /proc file was being accessed when this happened? This is happening _before_ the audit hooks in path_lookup() are reached; there shouldn't be anything happening in this particular code path which is audit-related. There's probably been some problem _beforehand_. Jeff, wasn't there a netdump in the x86_64 case above?

The second and third oopses are basically the same as each other. I'm inclined to suspect that it's the call to fops_get() in dentry_open(), which is actually another call to try_module_get(). But in that case it's a _different_ pointer to a struct module, not one in a proc_dir_entry but one in a struct file_operations. Again, what file is being access? One in /proc, I'd imagine?

How easy is it to reproduce these oopsen? Can it be done with audit disabled? Can it be done on the base U1 kernel?