linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Jim Schutt <jaschut@sandia.gov>
Subject: Re: [PATCH] Btrfs: fix a deadlock on chunk mutex
Date: Tue, 18 Dec 2012 08:52:42 -0500	[thread overview]
Message-ID: <20121218135242.GC2403@localhost.localdomain> (raw)
In-Reply-To: <1355363557-2962-1-git-send-email-bo.li.liu@oracle.com>

On Wed, Dec 12, 2012 at 06:52:37PM -0700, Liu Bo wrote:
> An user reported that he has hit an annoying deadlock while playing with
> ceph based on btrfs.
> 
> Current updating device tree requires space from METADATA chunk,
> so we -may- need to do a recursive chunk allocation when adding/updating
> dev extent, that is where the deadlock comes from.
> 
> If we use SYSTEM metadata to update device tree, we can avoid the recursive
> stuff.
> 

This is going to cause us to allocate much more system chunks than we used to
which could land us in trouble.  Instead let's just keep us from re-entering if
we're already allocating a chunk.  We do the chunk allocation when we don't have
enough space for a cluster, but we'll likely have plenty of space to make an
allocation.  Can you give this patch a try Jim and see if it fixes your problem?
Thanks,

Josef


diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index e152809..59df5e7 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3564,6 +3564,10 @@ static int do_chunk_alloc(struct btrfs_trans_handle *trans,
 	int wait_for_alloc = 0;
 	int ret = 0;
 
+	/* Don't re-enter if we're already allocating a chunk */
+	if (trans->allocating_chunk)
+		return -ENOSPC;
+
 	space_info = __find_space_info(extent_root->fs_info, flags);
 	if (!space_info) {
 		ret = update_space_info(extent_root->fs_info, flags,
@@ -3606,6 +3610,8 @@ again:
 		goto again;
 	}
 
+	trans->allocating_chunk = true;
+
 	/*
 	 * If we have mixed data/metadata chunks we want to make sure we keep
 	 * allocating mixed chunks instead of individual chunks.
@@ -3632,6 +3638,7 @@ again:
 	check_system_chunk(trans, extent_root, flags);
 
 	ret = btrfs_alloc_chunk(trans, extent_root, flags);
+	trans->allocating_chunk = false;
 	if (ret < 0 && ret != -ENOSPC)
 		goto out;
 
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index e6509b9..47ad8be 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -388,6 +388,7 @@ again:
 	h->qgroup_reserved = qgroup_reserved;
 	h->delayed_ref_elem.seq = 0;
 	h->type = type;
+	h->allocating_chunk = false;
 	INIT_LIST_HEAD(&h->qgroup_ref_list);
 	INIT_LIST_HEAD(&h->new_bgs);
 
diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h
index 0e8aa1e..69700f7 100644
--- a/fs/btrfs/transaction.h
+++ b/fs/btrfs/transaction.h
@@ -68,6 +68,7 @@ struct btrfs_trans_handle {
 	struct btrfs_block_rsv *orig_rsv;
 	short aborted;
 	short adding_csums;
+	bool allocating_chunk;
 	enum btrfs_trans_type type;
 	/*
 	 * this root is only needed to validate that the root passed to

  reply	other threads:[~2012-12-18 13:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-13  1:52 [PATCH] Btrfs: fix a deadlock on chunk mutex Liu Bo
2012-12-18 13:52 ` Josef Bacik [this message]
2012-12-18 14:47   ` Liu Bo
2012-12-18 15:40     ` Josef Bacik
2013-01-03 18:44   ` Jim Schutt
2013-01-28 21:23     ` Josef Bacik
2013-01-28 21:58       ` Jim Schutt
2013-01-29  2:30       ` Liu Bo
2013-01-29 13:47         ` Josef Bacik
2013-01-29 13:50           ` Josef Bacik
2013-01-29 16:43             ` David Sterba
2013-01-29 16:52               ` David Sterba
2013-01-29 18:41       ` Jim Schutt
2013-01-29 20:04         ` Josef Bacik
2013-01-29 20:37           ` Jim Schutt
2013-01-29 23:05           ` Jim Schutt
2013-01-30 15:06             ` Josef Bacik
2013-01-30 15:16             ` Josef Bacik
2013-01-30 16:38             ` Josef Bacik
2013-01-30 21:37               ` Jim Schutt
2013-01-30 21:55                 ` Josef Bacik
2013-01-31 15:33                 ` Josef Bacik
2013-01-31 16:52                   ` Jim Schutt
2014-02-18 15:47   ` Alex Lyakas
2014-02-18 16:06     ` Josef Bacik
2014-02-18 16:24       ` Alex Lyakas
2014-02-18 16:26         ` Josef Bacik

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=20121218135242.GC2403@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=bo.li.liu@oracle.com \
    --cc=jaschut@sandia.gov \
    --cc=linux-btrfs@vger.kernel.org \
    /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).