Patch "btrfs: fix reloc root leak with 0 ref reloc roots on recovery" has been added to the 5.11-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    btrfs: fix reloc root leak with 0 ref reloc roots on recovery

to the 5.11-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     btrfs-fix-reloc-root-leak-with-0-ref-reloc-roots-on-recovery.patch
and it can be found in the queue-5.11 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.


>From c78a10aebb275c38d0cfccae129a803fe622e305 Mon Sep 17 00:00:00 2001
From: Josef Bacik <josef@xxxxxxxxxxxxxx>
Date: Thu, 14 Jan 2021 14:02:42 -0500
Subject: btrfs: fix reloc root leak with 0 ref reloc roots on recovery

From: Josef Bacik <josef@xxxxxxxxxxxxxx>

commit c78a10aebb275c38d0cfccae129a803fe622e305 upstream.

When recovering a relocation, if we run into a reloc root that has 0
refs we simply add it to the reloc_control->reloc_roots list, and then
clean it up later.  The problem with this is __del_reloc_root() doesn't
do anything if the root isn't in the radix tree, which in this case it
won't be because we never call __add_reloc_root() on the reloc_root.

This exit condition simply isn't correct really.  During normal
operation we can remove ourselves from the rb tree and then we're meant
to clean up later at merge_reloc_roots() time, and this happens
correctly.  During recovery we're depending on free_reloc_roots() to
drop our references, but we're short-circuiting.

Fix this by continuing to check if we're on the list and dropping
ourselves from the reloc_control root list and dropping our reference
appropriately.  Change the corresponding BUG_ON() to an ASSERT() that
does the correct thing if we aren't in the rb tree.

CC: stable@xxxxxxxxxxxxxxx # 4.4+
Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
Reviewed-by: David Sterba <dsterba@xxxxxxxx>
Signed-off-by: David Sterba <dsterba@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 fs/btrfs/relocation.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -668,9 +668,7 @@ static void __del_reloc_root(struct btrf
 			RB_CLEAR_NODE(&node->rb_node);
 		}
 		spin_unlock(&rc->reloc_root_tree.lock);
-		if (!node)
-			return;
-		BUG_ON((struct btrfs_root *)node->data != root);
+		ASSERT(!node || (struct btrfs_root *)node->data == root);
 	}
 
 	/*


Patches currently in stable-queue which might be from josef@xxxxxxxxxxxxxx are

queue-5.11/btrfs-abort-the-transaction-if-we-fail-to-inc-ref-in-btrfs_copy_root.patch
queue-5.11/btrfs-handle-space_info-total_bytes_pinned-inside-the-delayed-ref-itself.patch
queue-5.11/btrfs-splice-remaining-dirty_bg-s-onto-the-transaction-dirty-bg-list.patch
queue-5.11/btrfs-do-not-warn-if-we-can-t-find-the-reloc-root-when-looking-up-backref.patch
queue-5.11/btrfs-fix-reloc-root-leak-with-0-ref-reloc-roots-on-recovery.patch
queue-5.11/btrfs-do-not-cleanup-upper-nodes-in-btrfs_backref_cleanup_node.patch
queue-5.11/btrfs-account-for-new-extents-being-deleted-in-total_bytes_pinned.patch
queue-5.11/proc-use-kvzalloc-for-our-kernel-buffer.patch
queue-5.11/btrfs-add-asserts-for-deleting-backref-cache-nodes.patch



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux