--- /dev/null
+From f37c563bab4297024c300b05c8f48430e323809d Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+Date: Fri, 10 Jul 2020 09:49:56 +0200
+Subject: btrfs: add missing check for nocow and compression inode flags
+
+From: David Sterba <dsterba@suse.com>
+
+commit f37c563bab4297024c300b05c8f48430e323809d upstream.
+
+User Forza reported on IRC that some invalid combinations of file
+attributes are accepted by chattr.
+
+The NODATACOW and compression file flags/attributes are mutually
+exclusive, but they could be set by 'chattr +c +C' on an empty file. The
+nodatacow will be in effect because it's checked first in
+btrfs_run_delalloc_range.
+
+Extend the flag validation to catch the following cases:
+
+ - input flags are conflicting
+ - old and new flags are conflicting
+ - initialize the local variable with inode flags after inode ls locked
+
+Inode attributes take precedence over mount options and are an
+independent setting.
+
+Nocompress would be a no-op with nodatacow, but we don't want to mix
+any compression-related options with nodatacow.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ioctl.c | 30 ++++++++++++++++++++++--------
+ 1 file changed, 22 insertions(+), 8 deletions(-)
+
+--- a/fs/btrfs/ioctl.c
++++ b/fs/btrfs/ioctl.c
+@@ -167,8 +167,11 @@ static int btrfs_ioctl_getflags(struct f
+ return 0;
+ }
+
+-/* Check if @flags are a supported and valid set of FS_*_FL flags */
+-static int check_fsflags(unsigned int flags)
++/*
++ * Check if @flags are a supported and valid set of FS_*_FL flags and that
++ * the old and new flags are not conflicting
++ */
++static int check_fsflags(unsigned int old_flags, unsigned int flags)
+ {
+ if (flags & ~(FS_IMMUTABLE_FL | FS_APPEND_FL | \
+ FS_NOATIME_FL | FS_NODUMP_FL | \
+@@ -177,9 +180,19 @@ static int check_fsflags(unsigned int fl
+ FS_NOCOW_FL))
+ return -EOPNOTSUPP;
+
++ /* COMPR and NOCOMP on new/old are valid */
+ if ((flags & FS_NOCOMP_FL) && (flags & FS_COMPR_FL))
+ return -EINVAL;
+
++ if ((flags & FS_COMPR_FL) && (flags & FS_NOCOW_FL))
++ return -EINVAL;
++
++ /* NOCOW and compression options are mutually exclusive */
++ if ((old_flags & FS_NOCOW_FL) && (flags & (FS_COMPR_FL | FS_NOCOMP_FL)))
++ return -EINVAL;
++ if ((flags & FS_NOCOW_FL) && (old_flags & (FS_COMPR_FL | FS_NOCOMP_FL)))
++ return -EINVAL;
++
+ return 0;
+ }
+
+@@ -193,7 +206,7 @@ static int btrfs_ioctl_setflags(struct f
+ unsigned int fsflags, old_fsflags;
+ int ret;
+ const char *comp = NULL;
+- u32 binode_flags = binode->flags;
++ u32 binode_flags;
+
+ if (!inode_owner_or_capable(inode))
+ return -EPERM;
+@@ -204,22 +217,23 @@ static int btrfs_ioctl_setflags(struct f
+ if (copy_from_user(&fsflags, arg, sizeof(fsflags)))
+ return -EFAULT;
+
+- ret = check_fsflags(fsflags);
+- if (ret)
+- return ret;
+-
+ ret = mnt_want_write_file(file);
+ if (ret)
+ return ret;
+
+ inode_lock(inode);
+-
+ fsflags = btrfs_mask_fsflags_for_type(inode, fsflags);
+ old_fsflags = btrfs_inode_flags_to_fsflags(binode->flags);
++
+ ret = vfs_ioc_setflags_prepare(inode, old_fsflags, fsflags);
+ if (ret)
+ goto out_unlock;
+
++ ret = check_fsflags(old_fsflags, fsflags);
++ if (ret)
++ goto out_unlock;
++
++ binode_flags = binode->flags;
+ if (fsflags & FS_SYNC_FL)
+ binode_flags |= BTRFS_INODE_SYNC;
+ else
--- /dev/null
+From 3502a8c0dc1bd4b4970b59b06e348f22a1c05581 Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+Date: Thu, 25 Jun 2020 12:35:28 +0200
+Subject: btrfs: allow use of global block reserve for balance item deletion
+
+From: David Sterba <dsterba@suse.com>
+
+commit 3502a8c0dc1bd4b4970b59b06e348f22a1c05581 upstream.
+
+On a filesystem with exhausted metadata, but still enough to start
+balance, it's possible to hit this error:
+
+[324402.053842] BTRFS info (device loop0): 1 enospc errors during balance
+[324402.060769] BTRFS info (device loop0): balance: ended with status: -28
+[324402.172295] BTRFS: error (device loop0) in reset_balance_state:3321: errno=-28 No space left
+
+It fails inside reset_balance_state and turns the filesystem to
+read-only, which is unnecessary and should be fixed too, but the problem
+is caused by lack for space when the balance item is deleted. This is a
+one-time operation and from the same rank as unlink that is allowed to
+use the global block reserve. So do the same for the balance item.
+
+Status of the filesystem (100GiB) just after the balance fails:
+
+$ btrfs fi df mnt
+Data, single: total=80.01GiB, used=38.58GiB
+System, single: total=4.00MiB, used=16.00KiB
+Metadata, single: total=19.99GiB, used=19.48GiB
+GlobalReserve, single: total=512.00MiB, used=50.11MiB
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/volumes.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -3283,7 +3283,7 @@ static int insert_balance_item(struct bt
+ if (!path)
+ return -ENOMEM;
+
+- trans = btrfs_start_transaction(root, 0);
++ trans = btrfs_start_transaction_fallback_global_rsv(root, 0);
+ if (IS_ERR(trans)) {
+ btrfs_free_path(path);
+ return PTR_ERR(trans);
--- /dev/null
+From f3e3d9cc35252a70a2fd698762c9687718268ec6 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Mon, 13 Jul 2020 09:03:20 +0800
+Subject: btrfs: avoid possible signal interruption of btrfs_drop_snapshot() on relocation tree
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit f3e3d9cc35252a70a2fd698762c9687718268ec6 upstream.
+
+[BUG]
+There is a bug report about bad signal timing could lead to read-only
+fs during balance:
+
+ BTRFS info (device xvdb): balance: start -d -m -s
+ BTRFS info (device xvdb): relocating block group 73001861120 flags metadata
+ BTRFS info (device xvdb): found 12236 extents, stage: move data extents
+ BTRFS info (device xvdb): relocating block group 71928119296 flags data
+ BTRFS info (device xvdb): found 3 extents, stage: move data extents
+ BTRFS info (device xvdb): found 3 extents, stage: update data pointers
+ BTRFS info (device xvdb): relocating block group 60922265600 flags metadata
+ BTRFS: error (device xvdb) in btrfs_drop_snapshot:5505: errno=-4 unknown
+ BTRFS info (device xvdb): forced readonly
+ BTRFS info (device xvdb): balance: ended with status: -4
+
+[CAUSE]
+The direct cause is the -EINTR from the following call chain when a
+fatal signal is pending:
+
+ relocate_block_group()
+ |- clean_dirty_subvols()
+ |- btrfs_drop_snapshot()
+ |- btrfs_start_transaction()
+ |- btrfs_delayed_refs_rsv_refill()
+ |- btrfs_reserve_metadata_bytes()
+ |- __reserve_metadata_bytes()
+ |- wait_reserve_ticket()
+ |- prepare_to_wait_event();
+ |- ticket->error = -EINTR;
+
+Normally this behavior is fine for most btrfs_start_transaction()
+callers, as they need to catch any other error, same for the signal, and
+exit ASAP.
+
+However for balance, especially for the clean_dirty_subvols() case, we're
+already doing cleanup works, getting -EINTR from btrfs_drop_snapshot()
+could cause a lot of unexpected problems.
+
+From the mentioned forced read-only report, to later balance error due
+to half dropped reloc trees.
+
+[FIX]
+Fix this problem by using btrfs_join_transaction() if
+btrfs_drop_snapshot() is called from relocation context.
+
+Since btrfs_join_transaction() won't get interrupted by signal, we can
+continue the cleanup.
+
+CC: stable@vger.kernel.org # 5.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>3
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent-tree.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -5221,7 +5221,14 @@ int btrfs_drop_snapshot(struct btrfs_roo
+ goto out;
+ }
+
+- trans = btrfs_start_transaction(tree_root, 0);
++ /*
++ * Use join to avoid potential EINTR from transaction start. See
++ * wait_reserve_ticket and the whole reservation callchain.
++ */
++ if (for_reloc)
++ trans = btrfs_join_transaction(tree_root);
++ else
++ trans = btrfs_start_transaction(tree_root, 0);
+ if (IS_ERR(trans)) {
+ err = PTR_ERR(trans);
+ goto out_free;
--- /dev/null
+From 851fd730a743e072badaf67caf39883e32439431 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Tue, 16 Jun 2020 10:17:34 +0800
+Subject: btrfs: don't allocate anonymous block device for user invisible roots
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 851fd730a743e072badaf67caf39883e32439431 upstream.
+
+[BUG]
+When a lot of subvolumes are created, there is a user report about
+transaction aborted:
+
+ BTRFS: Transaction aborted (error -24)
+ WARNING: CPU: 17 PID: 17041 at fs/btrfs/transaction.c:1576 create_pending_snapshot+0xbc4/0xd10 [btrfs]
+ RIP: 0010:create_pending_snapshot+0xbc4/0xd10 [btrfs]
+ Call Trace:
+ create_pending_snapshots+0x82/0xa0 [btrfs]
+ btrfs_commit_transaction+0x275/0x8c0 [btrfs]
+ btrfs_mksubvol+0x4b9/0x500 [btrfs]
+ btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs]
+ btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs]
+ btrfs_ioctl+0x11a4/0x2da0 [btrfs]
+ do_vfs_ioctl+0xa9/0x640
+ ksys_ioctl+0x67/0x90
+ __x64_sys_ioctl+0x1a/0x20
+ do_syscall_64+0x5a/0x110
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ ---[ end trace 33f2f83f3d5250e9 ]---
+ BTRFS: error (device sda1) in create_pending_snapshot:1576: errno=-24 unknown
+ BTRFS info (device sda1): forced readonly
+ BTRFS warning (device sda1): Skipping commit of aborted transaction.
+ BTRFS: error (device sda1) in cleanup_transaction:1831: errno=-24 unknown
+
+[CAUSE]
+The error is EMFILE (Too many files open) and comes from the anonymous
+block device allocation. The ids are in a shared pool of size 1<<20.
+
+The ids are assigned to live subvolumes, ie. the root structure exists
+in memory (eg. after creation or after the root appears in some path).
+The pool could be exhausted if the numbers are not reclaimed fast
+enough, after subvolume deletion or if other system component uses the
+anon block devices.
+
+[WORKAROUND]
+Since it's not possible to completely solve the problem, we can only
+minimize the time the id is allocated to a subvolume root.
+
+Firstly, we can reduce the use of anon_dev by trees that are not
+subvolume roots, like data reloc tree.
+
+This patch will do extra check on root objectid, to skip roots that
+don't need anon_dev. Currently it's only data reloc tree and orphan
+roots.
+
+Reported-by: Greed Rong <greedrong@gmail.com>
+Link: https://lore.kernel.org/linux-btrfs/CA+UqX+NTrZ6boGnWHhSeZmEY5J76CTqmYjO2S+=tHJX7nb9DPw@mail.gmail.com/
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/disk-io.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -1475,9 +1475,16 @@ int btrfs_init_fs_root(struct btrfs_root
+ spin_lock_init(&root->ino_cache_lock);
+ init_waitqueue_head(&root->ino_cache_wait);
+
+- ret = get_anon_bdev(&root->anon_dev);
+- if (ret)
+- goto fail;
++ /*
++ * Don't assign anonymous block device to roots that are not exposed to
++ * userspace, the id pool is limited to 1M
++ */
++ if (is_fstree(root->root_key.objectid) &&
++ btrfs_root_refs(&root->root_item) > 0) {
++ ret = get_anon_bdev(&root->anon_dev);
++ if (ret)
++ goto fail;
++ }
+
+ mutex_lock(&root->objectid_mutex);
+ ret = btrfs_find_highest_objectid(root,
--- /dev/null
+From 4faf55b03823e96c44dc4e364520000ed3b12fdb Mon Sep 17 00:00:00 2001
+From: Anand Jain <anand.jain@oracle.com>
+Date: Fri, 10 Jul 2020 14:37:38 +0800
+Subject: btrfs: don't traverse into the seed devices in show_devname
+
+From: Anand Jain <anand.jain@oracle.com>
+
+commit 4faf55b03823e96c44dc4e364520000ed3b12fdb upstream.
+
+->show_devname currently shows the lowest devid in the list. As the seed
+devices have the lowest devid in the sprouted filesystem, the userland
+tool such as findmnt end up seeing seed device instead of the device from
+the read-writable sprouted filesystem. As shown below.
+
+ mount /dev/sda /btrfs
+ mount: /btrfs: WARNING: device write-protected, mounted read-only.
+
+ findmnt --output SOURCE,TARGET,UUID /btrfs
+ SOURCE TARGET UUID
+ /dev/sda /btrfs 899f7027-3e46-4626-93e7-7d4c9ad19111
+
+ btrfs dev add -f /dev/sdb /btrfs
+
+ umount /btrfs
+ mount /dev/sdb /btrfs
+
+ findmnt --output SOURCE,TARGET,UUID /btrfs
+ SOURCE TARGET UUID
+ /dev/sda /btrfs 899f7027-3e46-4626-93e7-7d4c9ad19111
+
+All sprouts from a single seed will show the same seed device and the
+same fsid. That's confusing.
+This is causing problems in our prototype as there isn't any reference
+to the sprout file-system(s) which is being used for actual read and
+write.
+
+This was added in the patch which implemented the show_devname in btrfs
+commit 9c5085c14798 ("Btrfs: implement ->show_devname").
+I tried to look for any particular reason that we need to show the seed
+device, there isn't any.
+
+So instead, do not traverse through the seed devices, just show the
+lowest devid in the sprouted fsid.
+
+After the patch:
+
+ mount /dev/sda /btrfs
+ mount: /btrfs: WARNING: device write-protected, mounted read-only.
+
+ findmnt --output SOURCE,TARGET,UUID /btrfs
+ SOURCE TARGET UUID
+ /dev/sda /btrfs 899f7027-3e46-4626-93e7-7d4c9ad19111
+
+ btrfs dev add -f /dev/sdb /btrfs
+ mount -o rw,remount /dev/sdb /btrfs
+
+ findmnt --output SOURCE,TARGET,UUID /btrfs
+ SOURCE TARGET UUID
+ /dev/sdb /btrfs 595ca0e6-b82e-46b5-b9e2-c72a6928be48
+
+ mount /dev/sda /btrfs1
+ mount: /btrfs1: WARNING: device write-protected, mounted read-only.
+
+ btrfs dev add -f /dev/sdc /btrfs1
+
+ findmnt --output SOURCE,TARGET,UUID /btrfs1
+ SOURCE TARGET UUID
+ /dev/sdc /btrfs1 ca1dbb7a-8446-4f95-853c-a20f3f82bdbb
+
+ cat /proc/self/mounts | grep btrfs
+ /dev/sdb /btrfs btrfs rw,relatime,noacl,space_cache,subvolid=5,subvol=/ 0 0
+ /dev/sdc /btrfs1 btrfs ro,relatime,noacl,space_cache,subvolid=5,subvol=/ 0 0
+
+Reported-by: Martin K. Petersen <martin.petersen@oracle.com>
+CC: stable@vger.kernel.org # 4.19+
+Tested-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Anand Jain <anand.jain@oracle.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/super.c | 21 +++++++--------------
+ 1 file changed, 7 insertions(+), 14 deletions(-)
+
+--- a/fs/btrfs/super.c
++++ b/fs/btrfs/super.c
+@@ -2254,9 +2254,7 @@ static int btrfs_unfreeze(struct super_b
+ static int btrfs_show_devname(struct seq_file *m, struct dentry *root)
+ {
+ struct btrfs_fs_info *fs_info = btrfs_sb(root->d_sb);
+- struct btrfs_fs_devices *cur_devices;
+ struct btrfs_device *dev, *first_dev = NULL;
+- struct list_head *head;
+
+ /*
+ * Lightweight locking of the devices. We should not need
+@@ -2266,18 +2264,13 @@ static int btrfs_show_devname(struct seq
+ * least until the rcu_read_unlock.
+ */
+ rcu_read_lock();
+- cur_devices = fs_info->fs_devices;
+- while (cur_devices) {
+- head = &cur_devices->devices;
+- list_for_each_entry_rcu(dev, head, dev_list) {
+- if (test_bit(BTRFS_DEV_STATE_MISSING, &dev->dev_state))
+- continue;
+- if (!dev->name)
+- continue;
+- if (!first_dev || dev->devid < first_dev->devid)
+- first_dev = dev;
+- }
+- cur_devices = cur_devices->seed;
++ list_for_each_entry_rcu(dev, &fs_info->fs_devices->devices, dev_list) {
++ if (test_bit(BTRFS_DEV_STATE_MISSING, &dev->dev_state))
++ continue;
++ if (!dev->name)
++ continue;
++ if (!first_dev || dev->devid < first_dev->devid)
++ first_dev = dev;
+ }
+
+ if (first_dev)
--- /dev/null
+From f95ebdbed46a4d8b9fdb7bff109fdbb6fc9a6dc8 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Tue, 21 Jul 2020 11:24:27 -0400
+Subject: btrfs: don't WARN if we abort a transaction with EROFS
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit f95ebdbed46a4d8b9fdb7bff109fdbb6fc9a6dc8 upstream.
+
+If we got some sort of corruption via a read and call
+btrfs_handle_fs_error() we'll set BTRFS_FS_STATE_ERROR on the fs and
+complain. If a subsequent trans handle trips over this it'll get EROFS
+and then abort. However at that point we're not aborting for the
+original reason, we're aborting because we've been flipped read only.
+We do not need to WARN_ON() here.
+
+CC: stable@vger.kernel.org # 5.4+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ctree.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/ctree.h
++++ b/fs/btrfs/ctree.h
+@@ -3166,7 +3166,7 @@ do { \
+ /* Report first abort since mount */ \
+ if (!test_and_set_bit(BTRFS_FS_STATE_TRANS_ABORTED, \
+ &((trans)->fs_info->fs_state))) { \
+- if ((errno) != -EIO) { \
++ if ((errno) != -EIO && (errno) != -EROFS) { \
+ WARN(1, KERN_DEBUG \
+ "BTRFS: Transaction aborted (error %d)\n", \
+ (errno)); \
--- /dev/null
+From 3d6448e631591756da36efb3ea6355ff6f383c3a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 22 Jul 2020 12:28:37 +0100
+Subject: btrfs: fix race between page release and a fast fsync
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 3d6448e631591756da36efb3ea6355ff6f383c3a upstream.
+
+When releasing an extent map, done through the page release callback, we
+can race with an ongoing fast fsync and cause the fsync to miss a new
+extent and not log it. The steps for this to happen are the following:
+
+1) A page is dirtied for some inode I;
+
+2) Writeback for that page is triggered by a path other than fsync, for
+ example by the system due to memory pressure;
+
+3) When the ordered extent for the extent (a single 4K page) finishes,
+ we unpin the corresponding extent map and set its generation to N,
+ the current transaction's generation;
+
+4) The btrfs_releasepage() callback is invoked by the system due to
+ memory pressure for that no longer dirty page of inode I;
+
+5) At the same time, some task calls fsync on inode I, joins transaction
+ N, and at btrfs_log_inode() it sees that the inode does not have the
+ full sync flag set, so we proceed with a fast fsync. But before we get
+ into btrfs_log_changed_extents() and lock the inode's extent map tree:
+
+6) Through btrfs_releasepage() we end up at try_release_extent_mapping()
+ and we remove the extent map for the new 4Kb extent, because it is
+ neither pinned anymore nor locked. By calling remove_extent_mapping(),
+ we remove the extent map from the list of modified extents, since the
+ extent map does not have the logging flag set. We unlock the inode's
+ extent map tree;
+
+7) The task doing the fast fsync now enters btrfs_log_changed_extents(),
+ locks the inode's extent map tree and iterates its list of modified
+ extents, which no longer has the 4Kb extent in it, so it does not log
+ the extent;
+
+8) The fsync finishes;
+
+9) Before transaction N is committed, a power failure happens. After
+ replaying the log, the 4K extent of inode I will be missing, since
+ it was not logged due to the race with try_release_extent_mapping().
+
+So fix this by teaching try_release_extent_mapping() to not remove an
+extent map if it's still in the list of modified extents.
+
+Fixes: ff44c6e36dc9dc ("Btrfs: do not hold the write_lock on the extent tree while logging")
+CC: stable@vger.kernel.org # 5.4+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent_io.c | 16 +++++++++++++---
+ 1 file changed, 13 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/extent_io.c
++++ b/fs/btrfs/extent_io.c
+@@ -4467,15 +4467,25 @@ int try_release_extent_mapping(struct pa
+ free_extent_map(em);
+ break;
+ }
+- if (!test_range_bit(tree, em->start,
+- extent_map_end(em) - 1,
+- EXTENT_LOCKED, 0, NULL)) {
++ if (test_range_bit(tree, em->start,
++ extent_map_end(em) - 1,
++ EXTENT_LOCKED, 0, NULL))
++ goto next;
++ /*
++ * If it's not in the list of modified extents, used
++ * by a fast fsync, we can remove it. If it's being
++ * logged we can safely remove it since fsync took an
++ * extra reference on the em.
++ */
++ if (list_empty(&em->list) ||
++ test_bit(EXTENT_FLAG_LOGGING, &em->flags)) {
+ set_bit(BTRFS_INODE_NEEDS_FULL_SYNC,
+ &btrfs_inode->runtime_flags);
+ remove_extent_mapping(map, em);
+ /* once for the rb tree */
+ free_extent_map(em);
+ }
++next:
+ start = extent_map_end(em);
+ write_unlock(&map->lock);
+
--- /dev/null
+From 082b6c970f02fefd278c7833880cda29691a5f34 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Tue, 16 Jun 2020 10:17:37 +0800
+Subject: btrfs: free anon block device right after subvolume deletion
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 082b6c970f02fefd278c7833880cda29691a5f34 upstream.
+
+[BUG]
+When a lot of subvolumes are created, there is a user report about
+transaction aborted caused by slow anonymous block device reclaim:
+
+ BTRFS: Transaction aborted (error -24)
+ WARNING: CPU: 17 PID: 17041 at fs/btrfs/transaction.c:1576 create_pending_snapshot+0xbc4/0xd10 [btrfs]
+ RIP: 0010:create_pending_snapshot+0xbc4/0xd10 [btrfs]
+ Call Trace:
+ create_pending_snapshots+0x82/0xa0 [btrfs]
+ btrfs_commit_transaction+0x275/0x8c0 [btrfs]
+ btrfs_mksubvol+0x4b9/0x500 [btrfs]
+ btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs]
+ btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs]
+ btrfs_ioctl+0x11a4/0x2da0 [btrfs]
+ do_vfs_ioctl+0xa9/0x640
+ ksys_ioctl+0x67/0x90
+ __x64_sys_ioctl+0x1a/0x20
+ do_syscall_64+0x5a/0x110
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ ---[ end trace 33f2f83f3d5250e9 ]---
+ BTRFS: error (device sda1) in create_pending_snapshot:1576: errno=-24 unknown
+ BTRFS info (device sda1): forced readonly
+ BTRFS warning (device sda1): Skipping commit of aborted transaction.
+ BTRFS: error (device sda1) in cleanup_transaction:1831: errno=-24 unknown
+
+[CAUSE]
+The anonymous device pool is shared and its size is 1M. It's possible to
+hit that limit if the subvolume deletion is not fast enough and the
+subvolumes to be cleaned keep the ids allocated.
+
+[WORKAROUND]
+We can't avoid the anon device pool exhaustion but we can shorten the
+time the id is attached to the subvolume root once the subvolume becomes
+invisible to the user.
+
+Reported-by: Greed Rong <greedrong@gmail.com>
+Link: https://lore.kernel.org/linux-btrfs/CA+UqX+NTrZ6boGnWHhSeZmEY5J76CTqmYjO2S+=tHJX7nb9DPw@mail.gmail.com/
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/inode.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -4681,6 +4681,8 @@ int btrfs_delete_subvolume(struct inode
+ }
+ }
+
++ free_anon_bdev(dest->anon_dev);
++ dest->anon_dev = 0;
+ out_end_trans:
+ trans->block_rsv = NULL;
+ trans->bytes_reserved = 0;
--- /dev/null
+From 01d01caf19ff7c537527d352d169c4368375c0a1 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Fri, 17 Jul 2020 15:12:28 -0400
+Subject: btrfs: move the chunk_mutex in btrfs_read_chunk_tree
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 01d01caf19ff7c537527d352d169c4368375c0a1 upstream.
+
+We are currently getting this lockdep splat in btrfs/161:
+
+ ======================================================
+ WARNING: possible circular locking dependency detected
+ 5.8.0-rc5+ #20 Tainted: G E
+ ------------------------------------------------------
+ mount/678048 is trying to acquire lock:
+ ffff9b769f15b6e0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: clone_fs_devices+0x4d/0x170 [btrfs]
+
+ but task is already holding lock:
+ ffff9b76abdb08d0 (&fs_info->chunk_mutex){+.+.}-{3:3}, at: btrfs_read_chunk_tree+0x6a/0x800 [btrfs]
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:
+ __mutex_lock+0x8b/0x8f0
+ btrfs_init_new_device+0x2d2/0x1240 [btrfs]
+ btrfs_ioctl+0x1de/0x2d20 [btrfs]
+ ksys_ioctl+0x87/0xc0
+ __x64_sys_ioctl+0x16/0x20
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #0 (&fs_devs->device_list_mutex){+.+.}-{3:3}:
+ __lock_acquire+0x1240/0x2460
+ lock_acquire+0xab/0x360
+ __mutex_lock+0x8b/0x8f0
+ clone_fs_devices+0x4d/0x170 [btrfs]
+ btrfs_read_chunk_tree+0x330/0x800 [btrfs]
+ open_ctree+0xb7c/0x18ce [btrfs]
+ btrfs_mount_root.cold+0x13/0xfa [btrfs]
+ legacy_get_tree+0x30/0x50
+ vfs_get_tree+0x28/0xc0
+ fc_mount+0xe/0x40
+ vfs_kern_mount.part.0+0x71/0x90
+ btrfs_mount+0x13b/0x3e0 [btrfs]
+ legacy_get_tree+0x30/0x50
+ vfs_get_tree+0x28/0xc0
+ do_mount+0x7de/0xb30
+ __x64_sys_mount+0x8e/0xd0
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ other info that might help us debug this:
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(&fs_info->chunk_mutex);
+ lock(&fs_devs->device_list_mutex);
+ lock(&fs_info->chunk_mutex);
+ lock(&fs_devs->device_list_mutex);
+
+ *** DEADLOCK ***
+
+ 3 locks held by mount/678048:
+ #0: ffff9b75ff5fb0e0 (&type->s_umount_key#63/1){+.+.}-{3:3}, at: alloc_super+0xb5/0x380
+ #1: ffffffffc0c2fbc8 (uuid_mutex){+.+.}-{3:3}, at: btrfs_read_chunk_tree+0x54/0x800 [btrfs]
+ #2: ffff9b76abdb08d0 (&fs_info->chunk_mutex){+.+.}-{3:3}, at: btrfs_read_chunk_tree+0x6a/0x800 [btrfs]
+
+ stack backtrace:
+ CPU: 2 PID: 678048 Comm: mount Tainted: G E 5.8.0-rc5+ #20
+ Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./890FX Deluxe5, BIOS P1.40 05/03/2011
+ Call Trace:
+ dump_stack+0x96/0xd0
+ check_noncircular+0x162/0x180
+ __lock_acquire+0x1240/0x2460
+ ? asm_sysvec_apic_timer_interrupt+0x12/0x20
+ lock_acquire+0xab/0x360
+ ? clone_fs_devices+0x4d/0x170 [btrfs]
+ __mutex_lock+0x8b/0x8f0
+ ? clone_fs_devices+0x4d/0x170 [btrfs]
+ ? rcu_read_lock_sched_held+0x52/0x60
+ ? cpumask_next+0x16/0x20
+ ? module_assert_mutex_or_preempt+0x14/0x40
+ ? __module_address+0x28/0xf0
+ ? clone_fs_devices+0x4d/0x170 [btrfs]
+ ? static_obj+0x4f/0x60
+ ? lockdep_init_map_waits+0x43/0x200
+ ? clone_fs_devices+0x4d/0x170 [btrfs]
+ clone_fs_devices+0x4d/0x170 [btrfs]
+ btrfs_read_chunk_tree+0x330/0x800 [btrfs]
+ open_ctree+0xb7c/0x18ce [btrfs]
+ ? super_setup_bdi_name+0x79/0xd0
+ btrfs_mount_root.cold+0x13/0xfa [btrfs]
+ ? vfs_parse_fs_string+0x84/0xb0
+ ? rcu_read_lock_sched_held+0x52/0x60
+ ? kfree+0x2b5/0x310
+ legacy_get_tree+0x30/0x50
+ vfs_get_tree+0x28/0xc0
+ fc_mount+0xe/0x40
+ vfs_kern_mount.part.0+0x71/0x90
+ btrfs_mount+0x13b/0x3e0 [btrfs]
+ ? cred_has_capability+0x7c/0x120
+ ? rcu_read_lock_sched_held+0x52/0x60
+ ? legacy_get_tree+0x30/0x50
+ legacy_get_tree+0x30/0x50
+ vfs_get_tree+0x28/0xc0
+ do_mount+0x7de/0xb30
+ ? memdup_user+0x4e/0x90
+ __x64_sys_mount+0x8e/0xd0
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+This is because btrfs_read_chunk_tree() can come upon DEV_EXTENT's and
+then read the device, which takes the device_list_mutex. The
+device_list_mutex needs to be taken before the chunk_mutex, so this is a
+problem. We only really need the chunk mutex around adding the chunk,
+so move the mutex around read_one_chunk.
+
+An argument could be made that we don't even need the chunk_mutex here
+as it's during mount, and we are protected by various other locks.
+However we already have special rules for ->device_list_mutex, and I'd
+rather not have another special case for ->chunk_mutex.
+
+CC: stable@vger.kernel.org # 4.19+
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/volumes.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -7282,7 +7282,6 @@ int btrfs_read_chunk_tree(struct btrfs_f
+ * otherwise we don't need it.
+ */
+ mutex_lock(&uuid_mutex);
+- mutex_lock(&fs_info->chunk_mutex);
+
+ /*
+ * It is possible for mount and umount to race in such a way that
+@@ -7327,7 +7326,9 @@ int btrfs_read_chunk_tree(struct btrfs_f
+ } else if (found_key.type == BTRFS_CHUNK_ITEM_KEY) {
+ struct btrfs_chunk *chunk;
+ chunk = btrfs_item_ptr(leaf, slot, struct btrfs_chunk);
++ mutex_lock(&fs_info->chunk_mutex);
+ ret = read_one_chunk(&found_key, leaf, chunk);
++ mutex_unlock(&fs_info->chunk_mutex);
+ if (ret)
+ goto error;
+ }
+@@ -7357,7 +7358,6 @@ int btrfs_read_chunk_tree(struct btrfs_f
+ }
+ ret = 0;
+ error:
+- mutex_unlock(&fs_info->chunk_mutex);
+ mutex_unlock(&uuid_mutex);
+
+ btrfs_free_path(path);
--- /dev/null
+From 18c850fdc5a801bad4977b0f1723761d42267e45 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Fri, 17 Jul 2020 15:12:27 -0400
+Subject: btrfs: open device without device_list_mutex
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 18c850fdc5a801bad4977b0f1723761d42267e45 upstream.
+
+There's long existed a lockdep splat because we open our bdev's under
+the ->device_list_mutex at mount time, which acquires the bd_mutex.
+Usually this goes unnoticed, but if you do loopback devices at all
+suddenly the bd_mutex comes with a whole host of other dependencies,
+which results in the splat when you mount a btrfs file system.
+
+======================================================
+WARNING: possible circular locking dependency detected
+5.8.0-0.rc3.1.fc33.x86_64+debug #1 Not tainted
+------------------------------------------------------
+systemd-journal/509 is trying to acquire lock:
+ffff970831f84db0 (&fs_info->reloc_mutex){+.+.}-{3:3}, at: btrfs_record_root_in_trans+0x44/0x70 [btrfs]
+
+but task is already holding lock:
+ffff97083144d598 (sb_pagefaults){.+.+}-{0:0}, at: btrfs_page_mkwrite+0x59/0x560 [btrfs]
+
+which lock already depends on the new lock.
+
+the existing dependency chain (in reverse order) is:
+
+ -> #6 (sb_pagefaults){.+.+}-{0:0}:
+ __sb_start_write+0x13e/0x220
+ btrfs_page_mkwrite+0x59/0x560 [btrfs]
+ do_page_mkwrite+0x4f/0x130
+ do_wp_page+0x3b0/0x4f0
+ handle_mm_fault+0xf47/0x1850
+ do_user_addr_fault+0x1fc/0x4b0
+ exc_page_fault+0x88/0x300
+ asm_exc_page_fault+0x1e/0x30
+
+ -> #5 (&mm->mmap_lock#2){++++}-{3:3}:
+ __might_fault+0x60/0x80
+ _copy_from_user+0x20/0xb0
+ get_sg_io_hdr+0x9a/0xb0
+ scsi_cmd_ioctl+0x1ea/0x2f0
+ cdrom_ioctl+0x3c/0x12b4
+ sr_block_ioctl+0xa4/0xd0
+ block_ioctl+0x3f/0x50
+ ksys_ioctl+0x82/0xc0
+ __x64_sys_ioctl+0x16/0x20
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #4 (&cd->lock){+.+.}-{3:3}:
+ __mutex_lock+0x7b/0x820
+ sr_block_open+0xa2/0x180
+ __blkdev_get+0xdd/0x550
+ blkdev_get+0x38/0x150
+ do_dentry_open+0x16b/0x3e0
+ path_openat+0x3c9/0xa00
+ do_filp_open+0x75/0x100
+ do_sys_openat2+0x8a/0x140
+ __x64_sys_openat+0x46/0x70
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #3 (&bdev->bd_mutex){+.+.}-{3:3}:
+ __mutex_lock+0x7b/0x820
+ __blkdev_get+0x6a/0x550
+ blkdev_get+0x85/0x150
+ blkdev_get_by_path+0x2c/0x70
+ btrfs_get_bdev_and_sb+0x1b/0xb0 [btrfs]
+ open_fs_devices+0x88/0x240 [btrfs]
+ btrfs_open_devices+0x92/0xa0 [btrfs]
+ btrfs_mount_root+0x250/0x490 [btrfs]
+ legacy_get_tree+0x30/0x50
+ vfs_get_tree+0x28/0xc0
+ vfs_kern_mount.part.0+0x71/0xb0
+ btrfs_mount+0x119/0x380 [btrfs]
+ legacy_get_tree+0x30/0x50
+ vfs_get_tree+0x28/0xc0
+ do_mount+0x8c6/0xca0
+ __x64_sys_mount+0x8e/0xd0
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #2 (&fs_devs->device_list_mutex){+.+.}-{3:3}:
+ __mutex_lock+0x7b/0x820
+ btrfs_run_dev_stats+0x36/0x420 [btrfs]
+ commit_cowonly_roots+0x91/0x2d0 [btrfs]
+ btrfs_commit_transaction+0x4e6/0x9f0 [btrfs]
+ btrfs_sync_file+0x38a/0x480 [btrfs]
+ __x64_sys_fdatasync+0x47/0x80
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #1 (&fs_info->tree_log_mutex){+.+.}-{3:3}:
+ __mutex_lock+0x7b/0x820
+ btrfs_commit_transaction+0x48e/0x9f0 [btrfs]
+ btrfs_sync_file+0x38a/0x480 [btrfs]
+ __x64_sys_fdatasync+0x47/0x80
+ do_syscall_64+0x52/0xb0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #0 (&fs_info->reloc_mutex){+.+.}-{3:3}:
+ __lock_acquire+0x1241/0x20c0
+ lock_acquire+0xb0/0x400
+ __mutex_lock+0x7b/0x820
+ btrfs_record_root_in_trans+0x44/0x70 [btrfs]
+ start_transaction+0xd2/0x500 [btrfs]
+ btrfs_dirty_inode+0x44/0xd0 [btrfs]
+ file_update_time+0xc6/0x120
+ btrfs_page_mkwrite+0xda/0x560 [btrfs]
+ do_page_mkwrite+0x4f/0x130
+ do_wp_page+0x3b0/0x4f0
+ handle_mm_fault+0xf47/0x1850
+ do_user_addr_fault+0x1fc/0x4b0
+ exc_page_fault+0x88/0x300
+ asm_exc_page_fault+0x1e/0x30
+
+other info that might help us debug this:
+
+Chain exists of:
+ &fs_info->reloc_mutex --> &mm->mmap_lock#2 --> sb_pagefaults
+
+Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(sb_pagefaults);
+ lock(&mm->mmap_lock#2);
+ lock(sb_pagefaults);
+ lock(&fs_info->reloc_mutex);
+
+ *** DEADLOCK ***
+
+3 locks held by systemd-journal/509:
+ #0: ffff97083bdec8b8 (&mm->mmap_lock#2){++++}-{3:3}, at: do_user_addr_fault+0x12e/0x4b0
+ #1: ffff97083144d598 (sb_pagefaults){.+.+}-{0:0}, at: btrfs_page_mkwrite+0x59/0x560 [btrfs]
+ #2: ffff97083144d6a8 (sb_internal){.+.+}-{0:0}, at: start_transaction+0x3f8/0x500 [btrfs]
+
+stack backtrace:
+CPU: 0 PID: 509 Comm: systemd-journal Not tainted 5.8.0-0.rc3.1.fc33.x86_64+debug #1
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+Call Trace:
+ dump_stack+0x92/0xc8
+ check_noncircular+0x134/0x150
+ __lock_acquire+0x1241/0x20c0
+ lock_acquire+0xb0/0x400
+ ? btrfs_record_root_in_trans+0x44/0x70 [btrfs]
+ ? lock_acquire+0xb0/0x400
+ ? btrfs_record_root_in_trans+0x44/0x70 [btrfs]
+ __mutex_lock+0x7b/0x820
+ ? btrfs_record_root_in_trans+0x44/0x70 [btrfs]
+ ? kvm_sched_clock_read+0x14/0x30
+ ? sched_clock+0x5/0x10
+ ? sched_clock_cpu+0xc/0xb0
+ btrfs_record_root_in_trans+0x44/0x70 [btrfs]
+ start_transaction+0xd2/0x500 [btrfs]
+ btrfs_dirty_inode+0x44/0xd0 [btrfs]
+ file_update_time+0xc6/0x120
+ btrfs_page_mkwrite+0xda/0x560 [btrfs]
+ ? sched_clock+0x5/0x10
+ do_page_mkwrite+0x4f/0x130
+ do_wp_page+0x3b0/0x4f0
+ handle_mm_fault+0xf47/0x1850
+ do_user_addr_fault+0x1fc/0x4b0
+ exc_page_fault+0x88/0x300
+ ? asm_exc_page_fault+0x8/0x30
+ asm_exc_page_fault+0x1e/0x30
+RIP: 0033:0x7fa3972fdbfe
+Code: Bad RIP value.
+
+Fix this by not holding the ->device_list_mutex at this point. The
+device_list_mutex exists to protect us from modifying the device list
+while the file system is running.
+
+However it can also be modified by doing a scan on a device. But this
+action is specifically protected by the uuid_mutex, which we are holding
+here. We cannot race with opening at this point because we have the
+->s_mount lock held during the mount. Not having the
+->device_list_mutex here is perfectly safe as we're not going to change
+the devices at this point.
+
+CC: stable@vger.kernel.org # 4.19+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+[ add some comments ]
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/volumes.c | 21 ++++++++++++++++++---
+ 1 file changed, 18 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -219,7 +219,9 @@ static int __btrfs_map_block(struct btrf
+ *
+ * global::fs_devs - add, remove, updates to the global list
+ *
+- * does not protect: manipulation of the fs_devices::devices list!
++ * does not protect: manipulation of the fs_devices::devices list in general
++ * but in mount context it could be used to exclude list modifications by eg.
++ * scan ioctl
+ *
+ * btrfs_device::name - renames (write side), read is RCU
+ *
+@@ -232,6 +234,9 @@ static int __btrfs_map_block(struct btrf
+ * may be used to exclude some operations from running concurrently without any
+ * modifications to the list (see write_all_supers)
+ *
++ * Is not required at mount and close times, because our device list is
++ * protected by the uuid_mutex at that point.
++ *
+ * balance_mutex
+ * -------------
+ * protects balance structures (status, state) and context accessed from
+@@ -778,6 +783,11 @@ static int btrfs_free_stale_devices(cons
+ return ret;
+ }
+
++/*
++ * This is only used on mount, and we are protected from competing things
++ * messing with our fs_devices by the uuid_mutex, thus we do not need the
++ * fs_devices->device_list_mutex here.
++ */
+ static int btrfs_open_one_device(struct btrfs_fs_devices *fs_devices,
+ struct btrfs_device *device, fmode_t flags,
+ void *holder)
+@@ -1418,8 +1428,14 @@ int btrfs_open_devices(struct btrfs_fs_d
+ int ret;
+
+ lockdep_assert_held(&uuid_mutex);
++ /*
++ * The device_list_mutex cannot be taken here in case opening the
++ * underlying device takes further locks like bd_mutex.
++ *
++ * We also don't need the lock here as this is called during mount and
++ * exclusion is provided by uuid_mutex
++ */
+
+- mutex_lock(&fs_devices->device_list_mutex);
+ if (fs_devices->opened) {
+ fs_devices->opened++;
+ ret = 0;
+@@ -1427,7 +1443,6 @@ int btrfs_open_devices(struct btrfs_fs_d
+ list_sort(NULL, &fs_devices->devices, devid_cmp);
+ ret = open_fs_devices(fs_devices, flags, holder);
+ }
+- mutex_unlock(&fs_devices->device_list_mutex);
+
+ return ret;
+ }
--- /dev/null
+From d60ba8de1164e1b42e296ff270c622a070ef8fe7 Mon Sep 17 00:00:00 2001
+From: Tom Rix <trix@redhat.com>
+Date: Tue, 7 Jul 2020 06:29:08 -0700
+Subject: btrfs: ref-verify: fix memory leak in add_block_entry
+
+From: Tom Rix <trix@redhat.com>
+
+commit d60ba8de1164e1b42e296ff270c622a070ef8fe7 upstream.
+
+clang static analysis flags this error
+
+fs/btrfs/ref-verify.c:290:3: warning: Potential leak of memory pointed to by 're' [unix.Malloc]
+ kfree(be);
+ ^~~~~
+
+The problem is in this block of code:
+
+ if (root_objectid) {
+ struct root_entry *exist_re;
+
+ exist_re = insert_root_entry(&exist->roots, re);
+ if (exist_re)
+ kfree(re);
+ }
+
+There is no 'else' block freeing when root_objectid is 0. Add the
+missing kfree to the else branch.
+
+Fixes: fd708b81d972 ("Btrfs: add a extent ref verify tool")
+CC: stable@vger.kernel.org # 4.19+
+Signed-off-by: Tom Rix <trix@redhat.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ref-verify.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/ref-verify.c
++++ b/fs/btrfs/ref-verify.c
+@@ -286,6 +286,8 @@ static struct block_entry *add_block_ent
+ exist_re = insert_root_entry(&exist->roots, re);
+ if (exist_re)
+ kfree(re);
++ } else {
++ kfree(re);
+ }
+ kfree(be);
+ return exist;
--- /dev/null
+From 44d354abf33e92a5e73b965c84caf5a5d5e58a0b Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Mon, 13 Jul 2020 09:03:21 +0800
+Subject: btrfs: relocation: review the call sites which can be interrupted by signal
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 44d354abf33e92a5e73b965c84caf5a5d5e58a0b upstream.
+
+Since most metadata reservation calls can return -EINTR when get
+interrupted by fatal signal, we need to review the all the metadata
+reservation call sites.
+
+In relocation code, the metadata reservation happens in the following
+sites:
+
+- btrfs_block_rsv_refill() in merge_reloc_root()
+ merge_reloc_root() is a pretty critical section, we don't want to be
+ interrupted by signal, so change the flush status to
+ BTRFS_RESERVE_FLUSH_LIMIT, so it won't get interrupted by signal.
+ Since such change can be ENPSPC-prone, also shrink the amount of
+ metadata to reserve least amount avoid deadly ENOSPC there.
+
+- btrfs_block_rsv_refill() in reserve_metadata_space()
+ It calls with BTRFS_RESERVE_FLUSH_LIMIT, which won't get interrupted
+ by signal.
+
+- btrfs_block_rsv_refill() in prepare_to_relocate()
+
+- btrfs_block_rsv_add() in prepare_to_relocate()
+
+- btrfs_block_rsv_refill() in relocate_block_group()
+
+- btrfs_delalloc_reserve_metadata() in relocate_file_extent_cluster()
+
+- btrfs_start_transaction() in relocate_block_group()
+
+- btrfs_start_transaction() in create_reloc_inode()
+ Can be interrupted by fatal signal and we can handle it easily.
+ For these call sites, just catch the -EINTR value in btrfs_balance()
+ and count them as canceled.
+
+CC: stable@vger.kernel.org # 5.4+
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/relocation.c | 12 ++++++++++--
+ fs/btrfs/volumes.c | 17 ++++++++++++++++-
+ 2 files changed, 26 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -2312,12 +2312,20 @@ static noinline_for_stack int merge_relo
+ btrfs_unlock_up_safe(path, 0);
+ }
+
+- min_reserved = fs_info->nodesize * (BTRFS_MAX_LEVEL - 1) * 2;
++ /*
++ * In merge_reloc_root(), we modify the upper level pointer to swap the
++ * tree blocks between reloc tree and subvolume tree. Thus for tree
++ * block COW, we COW at most from level 1 to root level for each tree.
++ *
++ * Thus the needed metadata size is at most root_level * nodesize,
++ * and * 2 since we have two trees to COW.
++ */
++ min_reserved = fs_info->nodesize * btrfs_root_level(root_item) * 2;
+ memset(&next_key, 0, sizeof(next_key));
+
+ while (1) {
+ ret = btrfs_block_rsv_refill(root, rc->block_rsv, min_reserved,
+- BTRFS_RESERVE_FLUSH_ALL);
++ BTRFS_RESERVE_FLUSH_LIMIT);
+ if (ret) {
+ err = ret;
+ goto out;
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -4261,7 +4261,22 @@ int btrfs_balance(struct btrfs_fs_info *
+ mutex_lock(&fs_info->balance_mutex);
+ if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req))
+ btrfs_info(fs_info, "balance: paused");
+- else if (ret == -ECANCELED && atomic_read(&fs_info->balance_cancel_req))
++ /*
++ * Balance can be canceled by:
++ *
++ * - Regular cancel request
++ * Then ret == -ECANCELED and balance_cancel_req > 0
++ *
++ * - Fatal signal to "btrfs" process
++ * Either the signal caught by wait_reserve_ticket() and callers
++ * got -EINTR, or caught by btrfs_should_cancel_balance() and
++ * got -ECANCELED.
++ * Either way, in this case balance_cancel_req = 0, and
++ * ret == -EINTR or ret == -ECANCELED.
++ *
++ * So here we only check the return value to catch canceled balance.
++ */
++ else if (ret == -ECANCELED || ret == -EINTR)
+ btrfs_info(fs_info, "balance: canceled");
+ else
+ btrfs_info(fs_info, "balance: ended with status: %d", ret);
--- /dev/null
+From a93e01682e283f6de09d6ce8f805dc52a2e942fb Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 2 Jul 2020 12:32:40 +0100
+Subject: btrfs: remove no longer needed use of log_writers for the log root tree
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit a93e01682e283f6de09d6ce8f805dc52a2e942fb upstream.
+
+When syncing the log, we used to update the log root tree without holding
+neither the log_mutex of the subvolume root nor the log_mutex of log root
+tree.
+
+We used to have two critical sections delimited by the log_mutex of the
+log root tree, so in the first one we incremented the log_writers of the
+log root tree and on the second one we decremented it and waited for the
+log_writers counter to go down to zero. This was because the update of
+the log root tree happened between the two critical sections.
+
+The use of two critical sections allowed a little bit more of parallelism
+and required the use of the log_writers counter, necessary to make sure
+we didn't miss any log root tree update when we have multiple tasks trying
+to sync the log in parallel.
+
+However after commit 06989c799f0481 ("Btrfs: fix race updating log root
+item during fsync") the log root tree update was moved into a critical
+section delimited by the subvolume's log_mutex. Later another commit
+moved the log tree update from that critical section into the second
+critical section delimited by the log_mutex of the log root tree. Both
+commits addressed different bugs.
+
+The end result is that the first critical section delimited by the
+log_mutex of the log root tree became pointless, since there's nothing
+done between it and the second critical section, we just have an unlock
+of the log_mutex followed by a lock operation. This means we can merge
+both critical sections, as the first one does almost nothing now, and we
+can stop using the log_writers counter of the log root tree, which was
+incremented in the first critical section and decremented in the second
+criticial section, used to make sure no one in the second critical section
+started writeback of the log root tree before some other task updated it.
+
+So just remove the mutex_unlock() followed by mutex_lock() of the log root
+tree, as well as the use of the log_writers counter for the log root tree.
+
+This patch is part of a series that has the following patches:
+
+1/4 btrfs: only commit the delayed inode when doing a full fsync
+2/4 btrfs: only commit delayed items at fsync if we are logging a directory
+3/4 btrfs: stop incremening log_batch for the log root tree when syncing log
+4/4 btrfs: remove no longer needed use of log_writers for the log root tree
+
+After the entire patchset applied I saw about 12% decrease on max latency
+reported by dbench. The test was done on a qemu vm, with 8 cores, 16Gb of
+ram, using kvm and using a raw NVMe device directly (no intermediary fs on
+the host). The test was invoked like the following:
+
+ mkfs.btrfs -f /dev/sdk
+ mount -o ssd -o nospace_cache /dev/sdk /mnt/sdk
+ dbench -D /mnt/sdk -t 300 8
+ umount /mnt/dsk
+
+CC: stable@vger.kernel.org # 5.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ctree.h | 1 +
+ fs/btrfs/tree-log.c | 13 -------------
+ 2 files changed, 1 insertion(+), 13 deletions(-)
+
+--- a/fs/btrfs/ctree.h
++++ b/fs/btrfs/ctree.h
+@@ -990,6 +990,7 @@ struct btrfs_root {
+ wait_queue_head_t log_writer_wait;
+ wait_queue_head_t log_commit_wait[2];
+ struct list_head log_ctxs[2];
++ /* Used only for log trees of subvolumes, not for the log root tree */
+ atomic_t log_writers;
+ atomic_t log_commit[2];
+ /* Used only for log trees of subvolumes, not for the log root tree */
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -3140,28 +3140,17 @@ int btrfs_sync_log(struct btrfs_trans_ha
+ btrfs_init_log_ctx(&root_log_ctx, NULL);
+
+ mutex_lock(&log_root_tree->log_mutex);
+- atomic_inc(&log_root_tree->log_writers);
+
+ index2 = log_root_tree->log_transid % 2;
+ list_add_tail(&root_log_ctx.list, &log_root_tree->log_ctxs[index2]);
+ root_log_ctx.log_transid = log_root_tree->log_transid;
+
+- mutex_unlock(&log_root_tree->log_mutex);
+-
+- mutex_lock(&log_root_tree->log_mutex);
+-
+ /*
+ * Now we are safe to update the log_root_tree because we're under the
+ * log_mutex, and we're a current writer so we're holding the commit
+ * open until we drop the log_mutex.
+ */
+ ret = update_log_root(trans, log, &new_root_item);
+-
+- if (atomic_dec_and_test(&log_root_tree->log_writers)) {
+- /* atomic_dec_and_test implies a barrier */
+- cond_wake_up_nomb(&log_root_tree->log_writer_wait);
+- }
+-
+ if (ret) {
+ if (!list_empty(&root_log_ctx.list))
+ list_del_init(&root_log_ctx.list);
+@@ -3207,8 +3196,6 @@ int btrfs_sync_log(struct btrfs_trans_ha
+ root_log_ctx.log_transid - 1);
+ }
+
+- wait_for_writer(log_root_tree);
+-
+ /*
+ * now that we've moved on to the tree of log tree roots,
+ * check the full commit flag again
--- /dev/null
+From 28a9579561bcb9082715e720eac93012e708ab94 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 2 Jul 2020 12:32:31 +0100
+Subject: btrfs: stop incremening log_batch for the log root tree when syncing log
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 28a9579561bcb9082715e720eac93012e708ab94 upstream.
+
+We are incrementing the log_batch atomic counter of the root log tree but
+we never use that counter, it's used only for the log trees of subvolume
+roots. We started doing it when we moved the log_batch and log_write
+counters from the global, per fs, btrfs_fs_info structure, into the
+btrfs_root structure in commit 7237f1833601dc ("Btrfs: fix tree logs
+parallel sync").
+
+So just stop doing it for the log root tree and add a comment over the
+field declaration so inform it's used only for log trees of subvolume
+roots.
+
+This patch is part of a series that has the following patches:
+
+1/4 btrfs: only commit the delayed inode when doing a full fsync
+2/4 btrfs: only commit delayed items at fsync if we are logging a directory
+3/4 btrfs: stop incremening log_batch for the log root tree when syncing log
+4/4 btrfs: remove no longer needed use of log_writers for the log root tree
+
+After the entire patchset applied I saw about 12% decrease on max latency
+reported by dbench. The test was done on a qemu vm, with 8 cores, 16Gb of
+ram, using kvm and using a raw NVMe device directly (no intermediary fs on
+the host). The test was invoked like the following:
+
+ mkfs.btrfs -f /dev/sdk
+ mount -o ssd -o nospace_cache /dev/sdk /mnt/sdk
+ dbench -D /mnt/sdk -t 300 8
+ umount /mnt/dsk
+
+CC: stable@vger.kernel.org # 5.4+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ctree.h | 1 +
+ fs/btrfs/tree-log.c | 1 -
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/ctree.h
++++ b/fs/btrfs/ctree.h
+@@ -992,6 +992,7 @@ struct btrfs_root {
+ struct list_head log_ctxs[2];
+ atomic_t log_writers;
+ atomic_t log_commit[2];
++ /* Used only for log trees of subvolumes, not for the log root tree */
+ atomic_t log_batch;
+ int log_transid;
+ /* No matter the commit succeeds or not*/
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -3140,7 +3140,6 @@ int btrfs_sync_log(struct btrfs_trans_ha
+ btrfs_init_log_ctx(&root_log_ctx, NULL);
+
+ mutex_lock(&log_root_tree->log_mutex);
+- atomic_inc(&log_root_tree->log_batch);
+ atomic_inc(&log_root_tree->log_writers);
+
+ index2 = log_root_tree->log_transid % 2;
--- /dev/null
+From a47bd78d0c44621efb98b525d04d60dc4d1a79b0 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Tue, 21 Jul 2020 10:17:50 -0400
+Subject: btrfs: sysfs: use NOFS for device creation
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit a47bd78d0c44621efb98b525d04d60dc4d1a79b0 upstream.
+
+Dave hit this splat during testing btrfs/078:
+
+ ======================================================
+ WARNING: possible circular locking dependency detected
+ 5.8.0-rc6-default+ #1191 Not tainted
+ ------------------------------------------------------
+ kswapd0/75 is trying to acquire lock:
+ ffffa040e9d04ff8 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+
+ but task is already holding lock:
+ ffffffff8b0c8040 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #2 (fs_reclaim){+.+.}-{0:0}:
+ __lock_acquire+0x56f/0xaa0
+ lock_acquire+0xa3/0x440
+ fs_reclaim_acquire.part.0+0x25/0x30
+ __kmalloc_track_caller+0x49/0x330
+ kstrdup+0x2e/0x60
+ __kernfs_new_node.constprop.0+0x44/0x250
+ kernfs_new_node+0x25/0x50
+ kernfs_create_link+0x34/0xa0
+ sysfs_do_create_link_sd+0x5e/0xd0
+ btrfs_sysfs_add_devices_dir+0x65/0x100 [btrfs]
+ btrfs_init_new_device+0x44c/0x12b0 [btrfs]
+ btrfs_ioctl+0xc3c/0x25c0 [btrfs]
+ ksys_ioctl+0x68/0xa0
+ __x64_sys_ioctl+0x16/0x20
+ do_syscall_64+0x50/0xe0
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ -> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:
+ __lock_acquire+0x56f/0xaa0
+ lock_acquire+0xa3/0x440
+ __mutex_lock+0xa0/0xaf0
+ btrfs_chunk_alloc+0x137/0x3e0 [btrfs]
+ find_free_extent+0xb44/0xfb0 [btrfs]
+ btrfs_reserve_extent+0x9b/0x180 [btrfs]
+ btrfs_alloc_tree_block+0xc1/0x350 [btrfs]
+ alloc_tree_block_no_bg_flush+0x4a/0x60 [btrfs]
+ __btrfs_cow_block+0x143/0x7a0 [btrfs]
+ btrfs_cow_block+0x15f/0x310 [btrfs]
+ push_leaf_right+0x150/0x240 [btrfs]
+ split_leaf+0x3cd/0x6d0 [btrfs]
+ btrfs_search_slot+0xd14/0xf70 [btrfs]
+ btrfs_insert_empty_items+0x64/0xc0 [btrfs]
+ __btrfs_commit_inode_delayed_items+0xb2/0x840 [btrfs]
+ btrfs_async_run_delayed_root+0x10e/0x1d0 [btrfs]
+ btrfs_work_helper+0x2f9/0x650 [btrfs]
+ process_one_work+0x22c/0x600
+ worker_thread+0x50/0x3b0
+ kthread+0x137/0x150
+ ret_from_fork+0x1f/0x30
+
+ -> #0 (&delayed_node->mutex){+.+.}-{3:3}:
+ check_prev_add+0x98/0xa20
+ validate_chain+0xa8c/0x2a00
+ __lock_acquire+0x56f/0xaa0
+ lock_acquire+0xa3/0x440
+ __mutex_lock+0xa0/0xaf0
+ __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+ btrfs_evict_inode+0x3bf/0x560 [btrfs]
+ evict+0xd6/0x1c0
+ dispose_list+0x48/0x70
+ prune_icache_sb+0x54/0x80
+ super_cache_scan+0x121/0x1a0
+ do_shrink_slab+0x175/0x420
+ shrink_slab+0xb1/0x2e0
+ shrink_node+0x192/0x600
+ balance_pgdat+0x31f/0x750
+ kswapd+0x206/0x510
+ kthread+0x137/0x150
+ ret_from_fork+0x1f/0x30
+
+ other info that might help us debug this:
+
+ Chain exists of:
+ &delayed_node->mutex --> &fs_info->chunk_mutex --> fs_reclaim
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(fs_reclaim);
+ lock(&fs_info->chunk_mutex);
+ lock(fs_reclaim);
+ lock(&delayed_node->mutex);
+
+ *** DEADLOCK ***
+
+ 3 locks held by kswapd0/75:
+ #0: ffffffff8b0c8040 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
+ #1: ffffffff8b0b50b8 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x54/0x2e0
+ #2: ffffa040e057c0e8 (&type->s_umount_key#26){++++}-{3:3}, at: trylock_super+0x16/0x50
+
+ stack backtrace:
+ CPU: 2 PID: 75 Comm: kswapd0 Not tainted 5.8.0-rc6-default+ #1191
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
+ Call Trace:
+ dump_stack+0x78/0xa0
+ check_noncircular+0x16f/0x190
+ check_prev_add+0x98/0xa20
+ validate_chain+0xa8c/0x2a00
+ __lock_acquire+0x56f/0xaa0
+ lock_acquire+0xa3/0x440
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+ __mutex_lock+0xa0/0xaf0
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+ ? __lock_acquire+0x56f/0xaa0
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+ ? lock_acquire+0xa3/0x440
+ ? btrfs_evict_inode+0x138/0x560 [btrfs]
+ ? btrfs_evict_inode+0x2fe/0x560 [btrfs]
+ ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+ __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
+ btrfs_evict_inode+0x3bf/0x560 [btrfs]
+ evict+0xd6/0x1c0
+ dispose_list+0x48/0x70
+ prune_icache_sb+0x54/0x80
+ super_cache_scan+0x121/0x1a0
+ do_shrink_slab+0x175/0x420
+ shrink_slab+0xb1/0x2e0
+ shrink_node+0x192/0x600
+ balance_pgdat+0x31f/0x750
+ kswapd+0x206/0x510
+ ? _raw_spin_unlock_irqrestore+0x3e/0x50
+ ? finish_wait+0x90/0x90
+ ? balance_pgdat+0x750/0x750
+ kthread+0x137/0x150
+ ? kthread_stop+0x2a0/0x2a0
+ ret_from_fork+0x1f/0x30
+
+This is because we're holding the chunk_mutex while adding this device
+and adding its sysfs entries. We actually hold different locks in
+different places when calling this function, the dev_replace semaphore
+for instance in dev replace, so instead of moving this call around
+simply wrap it's operations in NOFS.
+
+CC: stable@vger.kernel.org # 4.14+
+Reported-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/sysfs.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/btrfs/sysfs.c
++++ b/fs/btrfs/sysfs.c
+@@ -975,7 +975,9 @@ int btrfs_sysfs_add_device_link(struct b
+ {
+ int error = 0;
+ struct btrfs_device *dev;
++ unsigned int nofs_flag;
+
++ nofs_flag = memalloc_nofs_save();
+ list_for_each_entry(dev, &fs_devices->devices, dev_list) {
+ struct hd_struct *disk;
+ struct kobject *disk_kobj;
+@@ -994,6 +996,7 @@ int btrfs_sysfs_add_device_link(struct b
+ if (error)
+ break;
+ }
++ memalloc_nofs_restore(nofs_flag);
+
+ return error;
+ }
pci-add-device-even-if-driver-attach-failed.patch
pci-qcom-define-some-parf-params-needed-for-ipq8064-soc.patch
pci-qcom-add-support-for-tx-term-offset-for-rev-2.1.0.patch
+btrfs-allow-use-of-global-block-reserve-for-balance-item-deletion.patch
+btrfs-free-anon-block-device-right-after-subvolume-deletion.patch
+btrfs-don-t-allocate-anonymous-block-device-for-user-invisible-roots.patch
+btrfs-ref-verify-fix-memory-leak-in-add_block_entry.patch
+btrfs-stop-incremening-log_batch-for-the-log-root-tree-when-syncing-log.patch
+btrfs-remove-no-longer-needed-use-of-log_writers-for-the-log-root-tree.patch
+btrfs-don-t-traverse-into-the-seed-devices-in-show_devname.patch
+btrfs-open-device-without-device_list_mutex.patch
+btrfs-move-the-chunk_mutex-in-btrfs_read_chunk_tree.patch
+btrfs-relocation-review-the-call-sites-which-can-be-interrupted-by-signal.patch
+btrfs-add-missing-check-for-nocow-and-compression-inode-flags.patch
+btrfs-avoid-possible-signal-interruption-of-btrfs_drop_snapshot-on-relocation-tree.patch
+btrfs-sysfs-use-nofs-for-device-creation.patch
+btrfs-don-t-warn-if-we-abort-a-transaction-with-erofs.patch
+btrfs-fix-race-between-page-release-and-a-fast-fsync.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
