From: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
To: Mark Fasheh <mfasheh@suse.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: Fri, 15 Jul 2011 11:43:52 +0900 [thread overview]
Message-ID: <4E1FA968.1070703@jp.fujitsu.com> (raw)
In-Reply-To: <1310681702-13922-7-git-send-email-mfasheh@suse.com>
(2011/07/15 7:15), Mark Fasheh wrote:
> 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.
>
> Signed-off-by: Mark Fasheh <mfasheh@suse.com>
> ---
> fs/btrfs/volumes.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> 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;
If find_next_chunk() returns -ENOMEM, space_info->full becomes 1 by following code.
3205 static int do_chunk_alloc(struct btrfs_trans_handle *trans,
3206 struct btrfs_root *extent_root, u64 alloc_bytes,
3207 u64 flags, int force)
3208 {
...
3277 ret = btrfs_alloc_chunk(trans, extent_root, flags);
3278 spin_lock(&space_info->lock);
3279 if (ret)
3280 space_info->full = 1;
3281 else
3282 ret = 1;
Is it OK?
Thanks,
Tsutomu
>
> 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 &
next prev parent reply other threads:[~2011-07-15 2:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
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-14 22:15 ` [PATCH 7/7] btrfs: don't BUG_ON allocation errors in btrfs_drop_snapshot Mark Fasheh
2011-07-15 3:04 ` Tsutomu Itoh
2011-07-18 22:09 ` Mark Fasheh
2011-07-19 0:07 ` Tsutomu Itoh
2011-07-27 17:49 ` Chris Mason
2011-07-15 2:43 ` Tsutomu Itoh [this message]
2011-07-18 21:36 ` [PATCH 6/7] btrfs: Don't BUG_ON alloc_path errors in find_next_chunk Mark Fasheh
2011-07-18 23:12 ` Chris Mason
2011-07-15 0:44 ` [PATCH 1/7] btrfs: don't BUG_ON btrfs_alloc_path() errors Tsutomu Itoh
2011-07-15 5:10 ` [PATCH 0/7] btrfs: don't BUG_ON btrfs_alloc_path errors Tsutomu Itoh
-- strict thread matches above, loose matches on Subject: below --
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-22 0:56 ` Tsutomu Itoh
2011-07-25 21:37 ` Mark Fasheh
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=4E1FA968.1070703@jp.fujitsu.com \
--to=t-itoh@jp.fujitsu.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=mfasheh@suse.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.