Created attachment 320976 [details] Oops message I'm trying to identify the other end of a unix domain socket using the tool from http://unix.stackexchange.com/a/16447/20807 in an attempt to make progress on bug #430286 comment #7. That tool works by using gdb on /proc/kcore. Executing that, I just got a kernel oops: BUG: unable to handle kernel paging request at ffffb029394236c8 IP: [<ffffffff81026b95>] kern_addr_valid+0xa5/0x120 … Call Trace: [<ffffffff8114e968>] ? read_kcore+0x248/0x350 [<ffffffff8114e720>] ? kclist_add_private+0x210/0x210 [<ffffffff81142600>] ? proc_reg_read+0x80/0xd0 [<ffffffff810ee973>] ? vfs_read+0xc3/0x180 [<ffffffff810eea7e>] ? sys_read+0x4e/0x90 [<ffffffff8139ebe2>] ? system_call_fastpath+0x16/0x1b I'll attach the full oops text. I understand that there might be illegal pointers in some kernel structures, although I wouldn't have expected them in this case. I imagine that dereferencing these pointers might cause errors similar to a segmentation fault in a user level application. But I would hope that /proc/kcore could isolate the kernel from any user-level abuse, and simply cause a read error instead of an oops. After all, I DID see read errors for other addresses in the past. So I believe (although I might be wrong) that the above is unintended behaviour and therefore a bug, just as the first line of the message claims.
I'm trying to be helpful here, I have not had much luck with this type of bug. I did find this reference to filing kernel bugs in the wiki- http://wiki.gentoo.org/wiki/Beautiful_bug_reports#Kernel Kernel Files and information of interest for kernel bug reports ordered by priority: which kernel and version is used on what architecture e.g. gentoo-sources-3.4.2-r2 on x86_64 the kernel config file should be attached to the bug report /usr/src/linux/.config a list of all devices in the system can be aquired with lspci -k log files during kernel intialization should be attached /var/log/dmesg or /var/log/messages So at the least /usr/src/linux/.config should be attached.
I think that would be stuff for a kernel bug. Is it reproducible and also happening on 3.5.2 or earlier versions?
(In reply to comment #2) > I think that would be stuff for a kernel bug. Is it reproducible and also > happening on 3.5.2 or earlier versions? I wrote that this is for 3.5.0, so I assume you meant "later" instead of "earlier". My attempt to reproduce this on 3.5.3 failed, which can either mean that this isn't easily reproducible, or fixed in that version. Not sure. I don't fancy downgrading to 3.5.0 again.
Ok, as this appears to be fixed in 3.5.3, I will close. Please reopen if you see this happen again.
