From: Mark Fasheh <mfasheh@suse.com>
To: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, chris.mason@oracle.com
Subject: Re: [PATCH 6/7] btrfs: Don't BUG_ON alloc_path errors in find_next_chunk
Date: Mon, 25 Jul 2011 14:37:51 -0700 [thread overview]
Message-ID: <20110725213751.GF6911@wotan.suse.de> (raw)
In-Reply-To: <4E28CAA0.2070801@jp.fujitsu.com>
On Fri, Jul 22, 2011 at 09:56:00AM +0900, Tsutomu Itoh wrote:
> > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> > index aa91773..ff339b2 100644
> > --- a/fs/btrfs/extent-tree.c
> > +++ b/fs/btrfs/extent-tree.c
> > @@ -3277,6 +3277,9 @@ again:
> > }
> >
> > ret = btrfs_alloc_chunk(trans, extent_root, flags);
> > + if (ret < 0 && ret != -ENOSPC)
> > + return ret;
> > +
>
> You need mutex_unlock() before return.
Of course... Here's an updated patch (git tree has also been updated).
Thanks,
--Mark
--
Mark Fasheh
From: Mark Fasheh <mfasheh@suse.com>
[PATCH] btrfs: Don't BUG_ON alloc_path errors in find_next_chunk
I also removed the BUG_ON from error return of find_next_chunk in
init_first_rw_device(). It turns out that the only caller of
init_first_rw_device() also BUGS on any nonzero return so no actual behavior
change has occurred here.
do_chunk_alloc() also needed an update since it calls btrfs_alloc_chunk()
which can now return -ENOMEM. Instead of setting space_info->full on any
error from btrfs_alloc_chunk() I catch and return every error value _except_
-ENOSPC. Thanks goes to Tsutomu Itoh for pointing that issue out.
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
---
fs/btrfs/extent-tree.c | 4 ++++
fs/btrfs/volumes.c | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index aa91773..f6af423 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3277,6 +3277,9 @@ again:
}
ret = btrfs_alloc_chunk(trans, extent_root, flags);
+ if (ret < 0 && ret != -ENOSPC)
+ goto out;
+
spin_lock(&space_info->lock);
if (ret)
space_info->full = 1;
@@ -3286,6 +3289,7 @@ again:
space_info->force_alloc = CHUNK_ALLOC_NO_FORCE;
space_info->chunk_alloc = 0;
spin_unlock(&space_info->lock);
+out:
mutex_unlock(&extent_root->fs_info->chunk_mutex);
return ret;
}
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 530a2fc..90d956c 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1037,7 +1037,8 @@ static noinline int find_next_chunk(struct btrfs_root *root,
struct btrfs_key found_key;
path = btrfs_alloc_path();
- BUG_ON(!path);
+ if (!path)
+ return -ENOMEM;
key.objectid = objectid;
key.offset = (u64)-1;
@@ -2663,7 +2664,8 @@ static noinline int init_first_rw_device(struct btrfs_trans_handle *trans,
ret = find_next_chunk(fs_info->chunk_root,
BTRFS_FIRST_CHUNK_TREE_OBJECTID, &chunk_offset);
- BUG_ON(ret);
+ if (ret)
+ return ret;
alloc_profile = BTRFS_BLOCK_GROUP_METADATA |
(fs_info->metadata_alloc_profile &
--
1.7.6
next prev parent reply other threads:[~2011-07-25 21:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-21 19:48 [PATCH 0/7] btrfs: don't BUG_ON btrfs_alloc_path errors v2 Mark Fasheh
2011-07-21 19:48 ` [PATCH 1/7] btrfs: don't BUG_ON btrfs_alloc_path() errors Mark Fasheh
2011-07-21 19:48 ` [PATCH 2/7] btrfs: Don't BUG_ON alloc_path errors in replay_one_buffer() Mark Fasheh
2011-07-21 19:48 ` [PATCH 3/7] btrfs: Don't BUG_ON alloc_path errors in btrfs_truncate_inode_items Mark Fasheh
2011-07-21 19:48 ` [PATCH 4/7] btrfs: Don't BUG_ON alloc_path errors in btrfs_read_locked_inode Mark Fasheh
2011-07-21 19:48 ` [PATCH 5/7] btrfs: Don't BUG_ON alloc_path errors in btrfs_balance() Mark Fasheh
2011-07-21 19:48 ` [PATCH 6/7] btrfs: Don't BUG_ON alloc_path errors in find_next_chunk Mark Fasheh
2011-07-21 19:48 ` [PATCH 7/7] btrfs: don't BUG_ON allocation errors in btrfs_drop_snapshot Mark Fasheh
2011-07-22 0:45 ` Tsutomu Itoh
2011-07-25 21:10 ` Mark Fasheh
2011-07-26 13:14 ` Justin Ossevoort
2011-07-22 0:56 ` [PATCH 6/7] btrfs: Don't BUG_ON alloc_path errors in find_next_chunk Tsutomu Itoh
2011-07-25 21:37 ` Mark Fasheh [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-07-14 22:14 [PATCH 0/7] btrfs: don't BUG_ON btrfs_alloc_path errors Mark Fasheh
2011-07-14 22:14 ` [PATCH 1/7] btrfs: don't BUG_ON btrfs_alloc_path() errors Mark Fasheh
2011-07-14 22:14 ` [PATCH 2/7] btrfs: Don't BUG_ON alloc_path errors in replay_one_buffer() Mark Fasheh
2011-07-14 22:14 ` [PATCH 3/7] btrfs: Don't BUG_ON alloc_path errors in btrfs_truncate_inode_items Mark Fasheh
2011-07-14 22:14 ` [PATCH 4/7] btrfs: Don't BUG_ON alloc_path errors in btrfs_read_locked_inode Mark Fasheh
2011-07-14 22:15 ` [PATCH 5/7] btrfs: Don't BUG_ON alloc_path errors in btrfs_balance() Mark Fasheh
2011-07-14 22:15 ` [PATCH 6/7] btrfs: Don't BUG_ON alloc_path errors in find_next_chunk Mark Fasheh
2011-07-15 2:43 ` Tsutomu Itoh
2011-07-18 21:36 ` Mark Fasheh
2011-07-18 23:12 ` Chris Mason
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=20110725213751.GF6911@wotan.suse.de \
--to=mfasheh@suse.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=t-itoh@jp.fujitsu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.