Patch "btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root" 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: abort the transaction if we fail to inc ref in btrfs_copy_root

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-abort-the-transaction-if-we-fail-to-inc-ref-in-btrfs_copy_root.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 867ed321f90d06aaba84e2c91de51cd3038825ef Mon Sep 17 00:00:00 2001
From: Josef Bacik <josef@xxxxxxxxxxxxxx>
Date: Thu, 14 Jan 2021 14:02:46 -0500
Subject: btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root

From: Josef Bacik <josef@xxxxxxxxxxxxxx>

commit 867ed321f90d06aaba84e2c91de51cd3038825ef upstream.

While testing my error handling patches, I added a error injection site
at btrfs_inc_extent_ref, to validate the error handling I added was
doing the correct thing.  However I hit a pretty ugly corruption while
doing this check, with the following error injection stack trace:

btrfs_inc_extent_ref
  btrfs_copy_root
    create_reloc_root
      btrfs_init_reloc_root
	btrfs_record_root_in_trans
	  btrfs_start_transaction
	    btrfs_update_inode
	      btrfs_update_time
		touch_atime
		  file_accessed
		    btrfs_file_mmap

This is because we do not catch the error from btrfs_inc_extent_ref,
which in practice would be ENOMEM, which means we lose the extent
references for a root that has already been allocated and inserted,
which is the problem.  Fix this by aborting the transaction if we fail
to do the reference modification.

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/ctree.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -221,9 +221,10 @@ int btrfs_copy_root(struct btrfs_trans_h
 		ret = btrfs_inc_ref(trans, root, cow, 1);
 	else
 		ret = btrfs_inc_ref(trans, root, cow, 0);
-
-	if (ret)
+	if (ret) {
+		btrfs_abort_transaction(trans, ret);
 		return ret;
+	}
 
 	btrfs_mark_buffer_dirty(cow);
 	*cow_ret = cow;


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