On Fri, Dec 23, 2005 at 10:51:47PM +0100, Blaisorblade wrote:
> [42949436.050000] Not tainted
> [42949436.050000] EAX: 00000000 EBX: 00003c02 ECX: 00000013 EDX: 00003c02
> [42949436.050000] ESI: 00003bfc EDI: 00000000 EBP: 40000fb8 DS: 002b ES: 002b
> [42949436.050000] a08ab2ac: [<a0032f7a>] show_regs+0x21a/0x230
> [42949436.050000] a08ab2dc: [<a0016edc>] panic_exit+0x2c/0x50
> [42949436.050000] a08ab2ec: [<a004ac85>] notifier_call_chain+0x25/0x40
> [42949436.050000] a08ab30c: [<a0037c01>] panic+0x71/0x100
> [42949436.050000] a08ab32c: [<a00162c5>] segv+0x285/0x2f0
> [42949436.050000] a08ab41c: [<a001660e>] segv_handler+0x9e/0x100
> [42949436.050000] a08ab44c: [<a001d1a2>] sig_handler_common_skas+0xf2/0x130
> [42949436.050000] a08ab47c: [<a002c1b3>] sig_handler+0x33/0x40
> [42949436.050000] a08ab48c: [<ffffe500>] _etext+0x5fdd0b4a/0x0
> [42949436.050000] a08ab7ec: [<a0149c9c>] kobject_unregister+0x2c/0x50
> [42949436.050000] a08ab80c: [<a016184c>] elv_unregister_queue+0x1c/0x30
> [42949436.050000] a08ab81c: [<a01669cd>] blk_unregister_queue+0x2d/0x60
> [42949436.050000] a08ab83c: [<a0167f72>] unlink_gendisk+0x12/0x30
> [42949436.050000] a08ab85c: [<a00ba52e>] del_gendisk+0x5e/0x110
> [42949436.050000] a08ab87c: [<a0026948>] ubd_remove+0x58/0x130
> [42949436.050000] a08ab9dc: [<a0024ff2>] mconsole_remove+0x152/0x180
> [42949436.050000] a08abb1c: [<a002450c>] mc_work_proc+0x4c/0x70
> [42949436.050000] a08abb2c: [<a004edde>] worker_thread+0x21e/0x2f0
> [42949436.050000] a08abbdc: [<a00531da>] kthread+0xaa/0xe0
> [42949436.050000] a08abc1c: [<a002c169>] run_kernel_thread+0x39/0x50
> [42949436.050000] a08abcdc: [<a001c7b4>] new_thread_handler+0xc4/0x120
> [42949436.050000] a08abd1c: [<ffffe500>] _etext+0x5fdd0b4a/0x0
At first glance, this appears to be a dentry reference count bug with a
sysfs block scheduler entry:
(gdb) p dentry
$1 = (struct dentry *) 0x13424c18
(gdb) p *$
$2 = {d_count = {counter = 1802201964}, d_flags = 1802201963, d_lock = {
raw_lock = {<No data fields>}}, d_inode = 0x6b6b6b6b, d_hash = {
next = 0x6b6b6b6b, pprev = 0x6b6b6b6b}, d_parent = 0x6b6b6b6b, d_name = {
hash = 1802201963, len = 1802201963,
name = 0x6b6b6b6b <Address 0x6b6b6b6b out of bounds>}, d_lru = {
next = 0x6b6b6b6b, prev = 0x6b6b6b6b}, d_child = {next = 0x6b6b6b6b,
prev = 0x6b6b6b6b}, d_subdirs = {next = 0x6b6b6b6b, prev = 0x6b6b6b6b},
d_alias = {next = 0x6b6b6b6b, prev = 0x6b6b6b6b}, d_time = 1802201963,
d_op = 0x6b6b6b6b, d_sb = 0x6b6b6b6b, d_fsdata = 0x6b6b6b6b, d_rcu = {
next = 0x6b6b6b6b, func = 0x6b6b6b6b}, d_cookie = 0x6b6b6b6b,
d_mounted = 1802201963, d_iname = 'k' <repeats 35 times>, "?"}
(gdb) p *kobj
$3 = {k_name = 0x0, name = "iosched", '\0' <repeats 12 times>, kref = {
refcount = {counter = 0}}, entry = {next = 0xabe6748, prev = 0xabe6748},
parent = 0x15cc5ebc, kset = 0x0, ktype = 0x8218b9c, dentry = 0x13424c18}
The kobj refcount is 0, so maybe that's the real problem, but in this case,
I don't see why it hasn't been freed.
The parents go like this:
(gdb) p *kobj.parent
$4 = {k_name = 0x0, name = "queue", '\0' <repeats 14 times>, kref = {
refcount = {counter = 0}}, entry = {next = 0x15cc5ed8, prev = 0x15cc5ed8},
parent = 0x15cc81f0, kset = 0x0, ktype = 0x82187e4, dentry = 0x13424cac}
(gdb) p *kobj.parent.parent
$5 = {k_name = 0x15cc81f4 "ubdc", name = "ubdc", '\0' <repeats 15 times>,
kref = {refcount = {counter = 4}}, entry = {next = 0x82188e8,
prev = 0x15cc8d90}, parent = 0x82188f0, kset = 0x82188e0, ktype = 0x0,
dentry = 0x13424244}
(gdb) p *kobj.parent.parent.parent
$6 = {k_name = 0x82188f4 "block", name = "block", '\0' <repeats 14 times>,
kref = {refcount = {counter = 8}}, entry = {next = 0x821890c,
prev = 0x821890c}, parent = 0x0, kset = 0x0, ktype = 0x0,
dentry = 0x15dc1cac}
"queue" also has a zero refcount from "ubdc", which doesn't look healthy.
Jeff
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
