Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 160233 - CPU deadlock in file_list_lock()
CPU deadlock in file_list_lock()
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Viro
Brian Brock
:
Depends On:
Blocks: 145411
  Show dependency tree / graph
 
Reported: 2005-06-13 14:39 EDT by Wendy Cheng
Modified: 2010-10-21 23:05 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-11 16:42:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for this issue. (561 bytes, patch)
2005-06-13 15:03 EDT, Wendy Cheng 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Wendy Cheng 2005-06-13 14:39:07 EDT 
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-07 23:17:19 EDT 
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.
First Last Prev Next    This bug is not in your last search results.