From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([222.73.24.84]:60329 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753620AbaCNMco (ORCPT ); Fri, 14 Mar 2014 08:32:44 -0400 Received: from fnstmail02.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1]) by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id s2EC6FD6023862 for ; Fri, 14 Mar 2014 20:06:16 +0800 Message-ID: <5322F03F.50703@cn.fujitsu.com> Date: Fri, 14 Mar 2014 20:04:15 +0800 From: Wang Shilong MIME-Version: 1.0 To: Josef Bacik CC: linux-btrfs@vger.kernel.org Subject: Re: [PATCH] Btrfs: fix joining same transaction handle more than twice References: <1394687987-22715-1-git-send-email-wangsl.fnst@cn.fujitsu.com> <5321BB2C.5000202@fb.com> In-Reply-To: <5321BB2C.5000202@fb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 03/13/2014 10:05 PM, Josef Bacik wrote: > On 03/13/2014 01:19 AM, Wang Shilong wrote: >> We hit something like the following function call flows: >> >> |->run_delalloc_range() >> |->btrfs_join_transaction() >> |->cow_file_range() >> |->btrfs_join_transaction() >> |->find_free_extent() >> |->btrfs_join_transaction() >> >> Trace infomation can be seen as: >> >> [ 7411.127040] ------------[ cut here ]------------ >> [ 7411.127060] WARNING: CPU: 0 PID: 11557 at fs/btrfs/transaction.c:383 start_transaction+0x561/0x580 [btrfs]() >> [ 7411.127079] CPU: 0 PID: 11557 Comm: kworker/u8:9 Tainted: G O 3.13.0+ #4 >> [ 7411.127080] Hardware name: LENOVO QiTianM4350/ , BIOS F1KT52AUS 05/24/2013 >> [ 7411.127085] Workqueue: writeback bdi_writeback_workfn (flush-btrfs-5) >> [ 7411.127092] Call Trace: >> [ 7411.127097] [] dump_stack+0x45/0x56 >> [ 7411.127101] [] warn_slowpath_common+0x7d/0xa0 >> [ 7411.127102] [] warn_slowpath_null+0x1a/0x20 >> [ 7411.127109] [] start_transaction+0x561/0x580 [btrfs] >> [ 7411.127115] [] btrfs_join_transaction+0x17/0x20 [btrfs] >> [ 7411.127120] [] find_free_extent+0xa21/0xb50 [btrfs] >> [ 7411.127126] [] btrfs_reserve_extent+0xa8/0x1a0 [btrfs] >> [ 7411.127131] [] btrfs_alloc_free_block+0xee/0x440 [btrfs] >> [ 7411.127137] [] ? btree_set_page_dirty+0xe/0x10 [btrfs] >> [ 7411.127142] [] __btrfs_cow_block+0x121/0x530 [btrfs] >> [ 7411.127146] [] btrfs_cow_block+0x11f/0x1c0 [btrfs] >> [ 7411.127151] [] btrfs_search_slot+0x1d4/0x9c0 [btrfs] >> [ 7411.127157] [] btrfs_lookup_file_extent+0x37/0x40 [btrfs] >> [ 7411.127163] [] __btrfs_drop_extents+0x16c/0xd90 [btrfs] >> [ 7411.127169] [] ? start_transaction+0x93/0x580 [btrfs] >> [ 7411.127171] [] ? kmem_cache_alloc+0x132/0x140 >> [ 7411.127176] [] ? btrfs_alloc_path+0x1a/0x20 [btrfs] >> [ 7411.127182] [] cow_file_range_inline+0x181/0x2e0 [btrfs] >> [ 7411.127187] [] cow_file_range+0x2ed/0x440 [btrfs] >> [ 7411.127194] [] ? free_extent_buffer+0x4f/0xb0 [btrfs] >> [ 7411.127200] [] run_delalloc_nocow+0x38f/0xa60 [btrfs] >> [ 7411.127207] [] ? test_range_bit+0x30/0x180 [btrfs] >> [ 7411.127212] [] run_delalloc_range+0x2e8/0x350 [btrfs] >> [ 7411.127219] [] ? find_lock_delalloc_range+0x1a9/0x1e0 [btrfs] >> [ 7411.127222] [] ? blk_queue_bio+0x2c1/0x330 >> [ 7411.127228] [] __extent_writepage+0x2f4/0x760 [btrfs] >> >> Here we fix it by avoiding joining transaction again if we have held >> a transaction handle when allocating chunk in find_free_extent(). >> >> > So I just put that warning there to see if we were ever embedding 3 > joins at a time, not because it was an actual problem, I'd say just kill > the warning. Thanks, We need keep @orgin_rsv and restore it when ending transaction. So we'd better not embed more than 2 joins now. Thanks, Wang > > Josef > > -- > 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 >