On Wed, Jan 10, 2018 at 11:55:34AM -0500, Josef Bacik wrote: > From: Josef Bacik <[email protected]> > > My delayed refs rsv patches uncovered a problem in > btrfs_alloc_data_chunk_ondemand where we don't clear ret before > returning, so we could have whatever left over value we had from trying > to do a chunk allocation or whatever that may have failed. Since we > know we've succeeded at this point just unconditionally return 0. This > fixed the xfstests failures I was seeing with my delayed refs rsv > patches. > > Signed-off-by: Josef Bacik <[email protected]> > --- > fs/btrfs/extent-tree.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index dbae25d882de..33c9efbfc9a7 100644 > --- a/fs/btrfs/extent-tree.c > +++ b/fs/btrfs/extent-tree.c > @@ -4387,8 +4387,7 @@ int btrfs_alloc_data_chunk_ondemand(struct btrfs_inode > *inode, u64 bytes) > trace_btrfs_space_reservation(fs_info, "space_info", > data_sinfo->flags, bytes, 1); > spin_unlock(&data_sinfo->lock); > - > - return ret; > + return 0;
I don't think this is the right way to fix it. The return code of do_chunk_alloc depends on the force parameter, and in case it's CHUNK_ALLOC_NO_FORCE the caller should handle all the possibilities, ie. negative/0/positive. Other callers do that, so I'd rather see it fixed right after do_chunk_alloc and not forcing 0. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
