Bug 5094
| Summary: | Get an ops message from the kernel with version 2.6.13.x | ||
|---|---|---|---|
| Product: | File System | Reporter: | Peter Poulsen (peter) |
| Component: | SysFS | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | dipankar, greg, kernel, protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.13-rc6 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | My .config for 2.16.13-rc6 | ||
|
Description
Peter Poulsen
2005-08-19 12:28:19 UTC
Greg, Dipankar; this looks a bit like Keith's use-after-free thing. Is that fix for that in 2.6.13-rc6-mm1? On Fri, Aug 19, 2005 at 01:01:51PM -0700, bugme-daemon@kernel-bugs.osdl.org wrote: > Is that fix for that in 2.6.13-rc6-mm1? Yes it is. This is something else. Care to attach your .config? Created attachment 5690 [details]
My .config for 2.16.13-rc6
Here it is
Doesn't look like Keith's attr use after free problem. This one seems to get a stale dentry or something in create_dir(). This looks like, is crashing due to NULL d_inode in the parent directory and it is not the use-after-free case of devt_attr. Considering vcs_make_devfs() in the call trace, I think here we are creating /sys/class/vc/vcs* or /sys/class/vcs/vcsa* direcotries and probably the parent directory /sys/class/vc does not exist. As directories are always pinned, so it is not expected that directory dentry and inode can go away if created once and the directory is not deleted. So there could be two possiblites here, one, that there was some error in creating /sys/class/vc, which was ignored and the caller went ahead and was trying to create /sys/class/vc/vcs* or there is some race between deleting /sys/class/vc and creating /sys/class/vc/vcs*. Re-building and running the kernel with the debug messages (pr_debug) for lib/kobject.c and drivers/base/class.c could tell us more about the events happening. If I could get some instructions on how to do that, it would be awesome. PS I do know how to code C, but I have never done kernel hacking. I think you need to enable the following kernel config options Device Drivers --> Generic Driver options --> Driver Core verbose debug messages and Kernel Hacking --> Kernel Debugging --> kobject Debugging Also try to capture all boot/console messages, you can use a serial console to do that. > Also try to capture all boot/console messages, you can use a serial console
> to
> do that.
I'm sorry for asking this, but what is a serial console, and how do I use it?
Using serial console you can electronicaly log all the console or boot messages. There is a simple documentation fot serial console in the kernel source tree. Documentation/serial-console.txt and a more detailed one at http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/ I finally got the time to look at this "serial-console" (sorry for the delay). Unfortunately my does neither have a serial nor a parallel port :-( Any ideas? serial-console is for logging the boot messages which you may miss. But if luck favours you may not need the serial-console and could "see" the debug messages other than the oops messages. If you use frame buffer, you could fit more messages on the screen than the plain VGA. Just try to recreate with the debugs options as mentioned earlier. I have now tried enabling the two debugging options. Unfortunately the screen I end up with is the same as without those options. Downstream bug report: http://bugs.gentoo.org/show_bug.cgi?id=101884 The bug mentioned in #14 specifies that the problem has been resolved upstream. If this is the case and the issue has been addressed then we can close the bug. Thanks. Actually it wasn't resolved, I was wrong there. But without more data from the reported it is not possible to resolve, and the rported kernel is hopelessly outdated now. Closing the bug. Please reopen if the problem still there. |