[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210125183216.981041812@linuxfoundation.org>
Date: Mon, 25 Jan 2021 19:37:19 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, Qu Wenruo <wqu@...e.com>,
Johannes Thumshirn <johannes.thumshirn@....com>,
Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>
Subject: [PATCH 5.10 017/199] btrfs: dont clear ret in btrfs_start_dirty_block_groups
From: Josef Bacik <josef@...icpanda.com>
commit 34d1eb0e599875064955a74712f08ff14c8e3d5f upstream.
If we fail to update a block group item in the loop we'll break, however
we'll do btrfs_run_delayed_refs and lose our error value in ret, and
thus not clean up properly. Fix this by only running the delayed refs
if there was no failure.
CC: stable@...r.kernel.org # 4.4+
Reviewed-by: Qu Wenruo <wqu@...e.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@....com>
Signed-off-by: Josef Bacik <josef@...icpanda.com>
Reviewed-by: David Sterba <dsterba@...e.com>
Signed-off-by: David Sterba <dsterba@...e.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
fs/btrfs/block-group.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -2687,7 +2687,8 @@ again:
* Go through delayed refs for all the stuff we've just kicked off
* and then loop back (just once)
*/
- ret = btrfs_run_delayed_refs(trans, 0);
+ if (!ret)
+ ret = btrfs_run_delayed_refs(trans, 0);
if (!ret && loops == 0) {
loops++;
spin_lock(&cur_trans->dirty_bgs_lock);
Powered by blists - more mailing lists