Re: [PATCH V5 2/2] btrfs: implement delayed inode items operation

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

On sun, 27 Mar 2011 20:09:10 +0900, Itaru Kitayama wrote:
> Hi Miao,
> 
> On Sun, 27 Mar 2011 15:00:00 +0800
> Miao Xie <miaox@cn.fujitsu.com> wrote:
> 
>> I got it. It is because the allocation flag of the metadata's page cache, which is stored in
>> the btree inode's i_mapping, was set to be GFP_HIGHUSER_MOVABLE. So if we allocate pages for
>> btree's page cache, this lockdep warning will be triggered.
>>
>> I think even without my patch, this lockdep warning can also be triggered, btrfs_evict_inode()
>> do the similar operations like what I do in the btrfs_destroy_inode(). 
>>   Task1					Kswap0 task
>>   open()
>>     ...
>>     btrfs_search_slot()
>>       ...
>>       btrfs_cow_block()
>> 	...
>> 	alloc_page()
>> 	  wait for reclaiming
>> 					shrink_slab()
>> 					  ...
>> 					  shrink_icache_memory()
>> 					    ...
>> 					    btrfs_evict_inode()
>> 					      ...
>> 					      btrfs_search_slot()
>>
>> If the path is locked by task1, the deadlock happens.
> 
> Ok. balance_pgdat() calls shrink_slab() with GFP_KERNEL so it's still possible for the kswapd0 
> to call prune_icache(), no? I still see the lockdep warning even with your patch that clears
> __GFP_FS in open_ctree().

sorry for my mistake. The above explanation is wrong, it has no business with kswap thread.
The correct explanation is

   Task1
   open()
     ...
     btrfs_search_slot()
       ...
       btrfs_cow_block()
 	...
 	alloc_page()
 	  do_try_to_free_pages()
 	    shrink_slab()
 	      ...
 	      shrink_icache_memory()
 		...
 		btrfs_evict_inode()
 		  ...
 		  btrfs_search_slot()

If the path is locked by task1, the deadlock happens.

So balance_pgdat() is impossible to trigger the lockdep.
(My clearing __GFP_FS patch's changelog is also wrong.)

I see, except btree's page cache, free space cache's page cache is also special,
can not use __GFP_FS flag.

Thanks
Miao

> itaru
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>