Re: [PATCH V4] btrfs: implement delayed inode items operation

[Miao Xie <miaox@cn.fujitsu.com>]

[-- Attachment #1: Type: text/plain, Size: 3612 bytes --]

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 <miaox@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

[-- Attachment #2: 0001-btrfs-use-GFP_NOFS-instead-of-GFP_KERNEL.patch --]
[-- Type: text/plain, Size: 953 bytes --]

>From f84daee1d2060beae945a2774cda7af2ef7f3e61 Mon Sep 17 00:00:00 2001
From: Miao Xie <miaox@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 <miaox@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