summaryrefslogtreecommitdiffstats
path: root/fs/adfs
diff options
context:
space:
mode:
authorVegard Nossum <vegard.nossum@gmail.com>2008-06-15 00:47:36 +0200
committerThomas Gleixner <tglx@linutronix.de>2008-06-18 11:09:54 +0200
commit50db04dd9c74178e68a981a7127c37252ffb3242 (patch)
treeac961b1ccc6f5073537be2b4b731bc79ec5448c4 /fs/adfs
parent952f4a0a9b27e6dbd5d32e330b3f609ebfa0b061 (diff)
downloadlinux-50db04dd9c74178e68a981a7127c37252ffb3242.tar.bz2
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 'fs/adfs')
0 files changed, 0 insertions, 0 deletions