Hi, Kitayama-san On wed, 23 Mar 2011 13:19:18 +0900, Itaru Kitayama wrote: > On Wed, 23 Mar 2011 12:00:38 +0800 > Miao Xie <mi...@cn.fujitsu.com> wrote: > >> I is testing the new version, in which I fixed the slab shrinker problem >> reported by >> Chris. In the new version, the delayed node is removed before the relative >> inode is >> moved into the unused_inode list(the slab shrinker will reclaim inodes in >> this list). >> Maybe this method can also fix this bug. So could you tell me the reproduce >> step >> or the options of mkfs and mount? I will check if the new patch can fix this >> bug or not. > > I used the default mkfs options for $TEST_DEV and enabled the space_cache and > the > compress=lzo options upon mounting the partition.
Unfortunately, I can trigger this warning, but by analyzing the following information, > ========================================================= > [ INFO: possible irq lock inversion dependency detected ] > 2.6.36-xie+ #122 > --------------------------------------------------------- > kswapd0/49 just changed the state of lock: > (iprune_sem){++++.-}, at: [<ffffffff811316d0>] > shrink_icache_memory+0x4d/0x213 > but this lock took another, RECLAIM_FS-unsafe lock in the past: > (&delayed_node->mutex){+.+.+.} > > and interrupts could create inverse lock ordering between them. [SNIP] > RECLAIM_FS-ON-W at: > [<ffffffff81074292>] mark_held_locks+0x52/0x70 > [<ffffffff81074354>] > lockdep_trace_alloc+0xa4/0xc2 > [<ffffffff8110f206>] __kmalloc+0x7f/0x154 > [<ffffffff811c2c21>] kzalloc+0x14/0x16 > [<ffffffff811c5e83>] > cache_block_group+0x106/0x238 > [<ffffffff811c7069>] find_free_extent+0x4e2/0xa86 > [<ffffffff811c76c1>] > btrfs_reserve_extent+0xb4/0x142 > [<ffffffff811c78b6>] > btrfs_alloc_free_block+0x167/0x2af > [<ffffffff811be610>] > __btrfs_cow_block+0x103/0x346 > [<ffffffff811bedb8>] btrfs_cow_block+0x101/0x110 > [<ffffffff811c05d8>] > btrfs_search_slot+0x143/0x513 > [<ffffffff811cf5ab>] btrfs_lookup_inode+0x2f/0x8f > [<ffffffff81212405>] > btrfs_update_delayed_inode+0x75/0x135 > [<ffffffff8121340d>] > btrfs_run_delayed_items+0xd6/0x131 > [<ffffffff811d64d7>] > btrfs_commit_transaction+0x28b/0x668 > [<ffffffff811ba786>] btrfs_sync_fs+0x6b/0x70 > [<ffffffff81140265>] __sync_filesystem+0x6b/0x83 > [<ffffffff81140347>] sync_filesystem+0x4c/0x50 > [<ffffffff8111fc56>] > generic_shutdown_super+0x27/0xd7 > [<ffffffff8111fd5b>] kill_anon_super+0x16/0x54 > [<ffffffff8111effd>] > deactivate_locked_super+0x26/0x46 > [<ffffffff8111f495>] deactivate_super+0x45/0x4a > [<ffffffff81135962>] mntput_no_expire+0xd6/0x104 > [<ffffffff81136a87>] sys_umount+0x2c1/0x2ec > [<ffffffff81002ddb>] > system_call_fastpath+0x16/0x1b we found GFP_KERNEL was passed into kzalloc(), I think this flag trigger the above lockdep warning. the attached patch, which against the delayed items operation patch, may fix this problem, Could you test it for me? Thanks Miao
>From f84daee1d2060beae945a2774cda7af2ef7f3e61 Mon Sep 17 00:00:00 2001 From: Miao Xie <mi...@cn.fujitsu.com> Date: Wed, 23 Mar 2011 16:01:16 +0800 Subject: [PATCH] btrfs: use GFP_NOFS instead of GFP_KERNEL In the filesystem context, we must allocate memory by GFP_NOFS, or we will start another filesystem operation and trigger lockdep warnning. Signed-off-by: Miao Xie <mi...@cn.fujitsu.com> --- fs/btrfs/extent-tree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index f1db57d..fe50cff 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -471,7 +471,7 @@ static int cache_block_group(struct btrfs_block_group_cache *cache, if (load_cache_only) return 0; - caching_ctl = kzalloc(sizeof(*caching_ctl), GFP_KERNEL); + caching_ctl = kzalloc(sizeof(*caching_ctl), GFP_NOFS); BUG_ON(!caching_ctl); INIT_LIST_HEAD(&caching_ctl->list); -- 1.7.3.1