From: Liu Bo <bo.li.liu@oracle.com>
To: Jan Schmidt <list.btrfs@jan-o-sch.net>
Cc: chris.mason@fusionio.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: drop locks before calling read_tree_block from get_old_root
Date: Wed, 24 Oct 2012 22:18:48 +0800 [thread overview]
Message-ID: <5087F8C8.40605@oracle.com> (raw)
In-Reply-To: <1351075516-16344-1-git-send-email-list.btrfs@jan-o-sch.net>
On 10/24/2012 06:45 PM, Jan Schmidt wrote:
> get_old_root needs its lock on the root node only to clone that buffer.
> However, when we call read_tree_block, we know already that we're not
> going to clone the root node. Thus we can safely unlock before, to avoid
> issues where read_tree_block makes potentially sleeping allocations.
>
I tested this for 20 times, it's no more blocked.
So you can add
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Tested-by: Liu Bo <bo.li.liu@oracle.com>
thanks,
liubo
> Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
> ---
> Thanks for pointing that out, liubo!
>
> I added this additional patch on top of my patch staple at:
>
> git://git.jan-o-sch.net/btrfs-unstable for-chris
>
> I also made a second branch, because this last commit actually fixes
> that's introduced by one of the patches in the patch set. So I folded
> it into the respective commit:
>
> git://git.jan-o-sch.net/btrfs-unstable for-chris-fixed
>
> I made sure that the resulting code is the same.
>
> Chris: please pull either one for rc3.
>
> -Jan
>
> ---
> fs/btrfs/ctree.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> index c608b3c..eba44b0 100644
> --- a/fs/btrfs/ctree.c
> +++ b/fs/btrfs/ctree.c
> @@ -1261,6 +1261,8 @@ get_old_root(struct btrfs_root *root, u64 time_seq)
>
> tm = tree_mod_log_search(root->fs_info, logical, time_seq);
> if (old_root && tm && tm->op != MOD_LOG_KEY_REMOVE_WHILE_FREEING) {
> + btrfs_tree_read_unlock(root->node);
> + free_extent_buffer(root->node);
> blocksize = btrfs_level_size(root, old_root->level);
> eb = read_tree_block(root, logical, blocksize, 0);
> if (!eb) {
> @@ -1271,12 +1273,15 @@ get_old_root(struct btrfs_root *root, u64 time_seq)
> eb = btrfs_clone_extent_buffer(eb);
> }
> } else if (old_root) {
> + btrfs_tree_read_unlock(root->node);
> + free_extent_buffer(root->node);
> eb = alloc_dummy_extent_buffer(logical, root->nodesize);
> } else {
> eb = btrfs_clone_extent_buffer(root->node);
> + btrfs_tree_read_unlock(root->node);
> + free_extent_buffer(root->node);
> }
> - btrfs_tree_read_unlock(root->node);
> - free_extent_buffer(root->node);
> +
> if (!eb)
> return NULL;
> extent_buffer_get(eb);
>
next prev parent reply other threads:[~2012-10-24 14:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 13:55 [PATCH 0/6] Btrfs: tree mod log fixes for 3.7-rc3 Jan Schmidt
2012-10-23 13:55 ` [PATCH 1/6] Btrfs: don't put removals from push_node_left into tree mod log twice Jan Schmidt
2012-10-23 15:23 ` Liu Bo
2012-10-23 13:55 ` [PATCH 2/6] Btrfs: fix a tree mod logging issue for root replacement operations Jan Schmidt
2012-10-23 15:28 ` Liu Bo
2012-10-23 15:51 ` Jan Schmidt
2012-10-23 13:55 ` [PATCH 3/6] Btrfs: tree mod log's old roots could still be part of the tree Jan Schmidt
2012-10-23 15:30 ` Liu Bo
2012-10-24 9:55 ` Liu Bo
2012-10-24 10:45 ` [PATCH] Btrfs: drop locks before calling read_tree_block from get_old_root Jan Schmidt
2012-10-24 14:18 ` Liu Bo [this message]
2012-10-23 13:55 ` [PATCH 4/6] Btrfs: determine level of old roots Jan Schmidt
2012-10-23 15:31 ` Liu Bo
2012-10-23 13:55 ` [PATCH 5/6] Btrfs: fix extent buffer reference for tree mod log roots Jan Schmidt
2012-10-23 15:32 ` Liu Bo
2012-10-23 13:55 ` [PATCH 6/6] Btrfs: comment for loop in tree_mod_log_insert_move Jan Schmidt
2012-10-23 15:32 ` Liu Bo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5087F8C8.40605@oracle.com \
--to=bo.li.liu@oracle.com \
--cc=chris.mason@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).