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: 1. 2. 3. Actual results: Expected results: Additional info:
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.