diff options
author | Vegard Nossum <vegard.nossum@gmail.com> | 2008-06-15 00:47:36 +0200 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2008-06-18 11:09:54 +0200 |
commit | 50db04dd9c74178e68a981a7127c37252ffb3242 (patch) | |
tree | ac961b1ccc6f5073537be2b4b731bc79ec5448c4 /ipc | |
parent | 952f4a0a9b27e6dbd5d32e330b3f609ebfa0b061 (diff) |
debugobjects: fix lockdep warning
Daniel J Blueman reported:
| =======================================================
| [ INFO: possible circular locking dependency detected ]
| 2.6.26-rc5-201c #1
| -------------------------------------------------------
| nscd/3669 is trying to acquire lock:
| (&n->list_lock){.+..}, at: [<ffffffff802bab03>] deactivate_slab+0x173/0x1e0
|
| but task is already holding lock:
| (&obj_hash[i].lock){++..}, at: [<ffffffff803fa56f>]
| __debug_object_init+0x2f/0x350
|
| which lock already depends on the new lock.
There are two locks involved here; the first is a SLUB-local lock, and
the second is a debugobjects-local lock. They are basically taken in two
different orders:
1. SLUB { debugobjects { ... } }
2. debugobjects { SLUB { ... } }
This patch changes pattern #2 by trying to fill the memory pool (e.g.
the call into SLUB/kmalloc()) outside the debugobjects lock, so now the
two patterns look like this:
1. SLUB { debugobjects { ... } }
2. SLUB { } debugobjects { ... }
[ daniel.blueman@gmail.com: pool_lock needs to be taken irq safe in fill_pool ]
Reported-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions