| Message ID | 1310681702-13922-7-git-send-email-mfasheh@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
(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 & -- 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
Hi Tsutomu, Thanks for the review, it is appreciated! On Fri, Jul 15, 2011 at 11:43:52AM +0900, Tsutomu Itoh wrote: > > @@ -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? I don't think so actually. It looks like in this case we might want to bubble the error back up past do_chunk_alloc and leave space_info untouched. Chris, does that seem reasonable? --Mark -- Mark Fasheh -- 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
Excerpts from Mark Fasheh's message of 2011-07-18 17:36:57 -0400: > Hi Tsutomu, > > Thanks for the review, it is appreciated! > > On Fri, Jul 15, 2011 at 11:43:52AM +0900, Tsutomu Itoh wrote: > > > @@ -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? > > I don't think so actually. It looks like in this case we might want to > bubble the error back up past do_chunk_alloc and leave space_info untouched. > Chris, does that seem reasonable? Yeah, once space_info->full is 1, we don't flip it back to zero until more space is available somehow. We should bubble the error up. -chris -- 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
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 &
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(-)