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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html