Bug 160233

Summary: CPU deadlock in file_list_lock()
Product: Red Hat Enterprise Linux 4 Reporter: Wendy Cheng <nobody+wcheng>
Component: kernelAssignee: Alexander Viro <aviro>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-07-11 20:42:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 145411    
Attachments:
Description Flags
Patch for this issue. none

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:
1.
2.
3.
  
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.