Bug 160233 - CPU deadlock in file_list_lock()
Summary: CPU deadlock in file_list_lock()
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Alexander Viro
QA Contact: Brian Brock
Depends On:
Blocks: 145411
TreeView+ depends on / blocked
Reported: 2005-06-13 18:39 UTC by Wendy Cheng
Modified: 2010-10-22 03:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-11 20:42:10 UTC
Target Upstream Version:

Attachments (Terms of Use)
Patch for this issue. (561 bytes, patch)
2005-06-13 19:03 UTC, Wendy Cheng
no flags Details | Diff

Description Wendy Cheng 2005-06-13 18:39:07 UTC
Description of problem:

An obvious deadlock caught by the following thread back trace:

Call Trace: (pid 4256, hotplug)
[<a000000100008cb0>] ia64_spinlock_contention+0x30/0x60
                               sp=e0000040db437bb0 bsp=e0000040db431338
[<a000000100555480>] __lock_text_start+0x40/0x60
                               sp=e0000040db437bb0 bsp=e0000040db431330
[<a000000100194690>] remove_proc_entry+0x1b0/0x560
                               sp=e0000040db437bb0 bsp=e0000040db4312f8
[<a0000002003d8aa0>] snmp6_unregister_dev+0xa0/0xe0 [ipv6]
                               sp=e0000040db437bc0 bsp=e0000040db4312d8
[<a00000020037cd40>] in6_dev_finish_destroy+0x140/0x240 [ipv6]
                               sp=e0000040db437bc0 bsp=e0000040db4312b0
[<a00000020038e770>] ip6_dst_destroy+0x90/0xc0 [ipv6]
                               sp=e0000040db437bc0 bsp=e0000040db431290
[<a000000100463ab0>] dst_destroy+0x230/0x280
                               sp=e0000040db437bc0 bsp=e0000040db431258
[<a000000100463d40>] dst_run_gc+0x240/0x2c0
                               sp=e0000040db437bc0 bsp=e0000040db431228
[<a000000100086630>] run_timer_softirq+0x250/0x420
                               sp=e0000040db437bc0 bsp=e0000040db4311a8
[<a00000010007c610>] __do_softirq+0x1f0/0x240
                               sp=e0000040db437be0 bsp=e0000040db431118
[<a00000010007c6d0>] do_softirq+0x70/0xc0
                               sp=e0000040db437be0 bsp=e0000040db4310b8
[<a000000100015a70>] ia64_handle_irq+0x1b0/0x1e0
                               sp=e0000040db437be0 bsp=e0000040db431070
[<a00000010000f480>] ia64_leave_kernel+0x0/0x260
                               sp=e0000040db437be0 bsp=e0000040db431070
[<a000000100111be0>] file_move+0x80/0xe0
                               sp=e0000040db437db0 bsp=e0000040db431040
[<a00000010010d5c0>] dentry_open+0x1a0/0x500
                               sp=e0000040db437db0 bsp=e0000040db430fc8
[<a00000010012a7e0>] open_exec+0x140/0x1e0
                               sp=e0000040db437db0 bsp=e0000040db430f98
[<a00000010012cff0>] do_execve+0x30/0x540
                               sp=e0000040db437e30 bsp=e0000040db430f20
[<a0000001000186a0>] sys_execve+0x60/0x100
                               sp=e0000040db437e30 bsp=e0000040db430ea8
[<a00000010000ea50>] ia64_execve+0x30/0x140
                               sp=e0000040db437e30 bsp=e0000040db430e80
[<a00000010000f320>] ia64_ret_from_syscall+0x0/0x20
                               sp=e0000040db437e30 bsp=e0000040db430e80
[<a000000000010640>] 0xa000000000010640
                               sp=e0000040db438000 bsp=e0000040db430e80

where file_move() (via dentry_open) has obtained the files_lock (global lock
handled by file_list(un)lock() macros). The subsequent interrupt kicks off
do_softirq() that ends up in proc_kill_inodes() waiting for the same lock. 

Upstream patch available.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 10 Wendy Cheng 2005-07-08 03:17:19 UTC
The problem can be fixed either by

* restructuring snmp (patch embedded in comment #2) or 
* changing vfs locking macros (patch proposed to rhkernel-list). 

Since our discussion had been focusing on vfs locking macro, no one remembered
to check the snmp patch. It turns out it (snmp) has been committed sometime ago
in U1.

Case closed.

Note You need to log in before you can comment on or make changes to this bug.