+++ /dev/null
-From 0568e82dbe2510fc1fa664f58e5c997d3f1e649e Mon Sep 17 00:00:00 2001
-From: Josef Bacik <jbacik@fb.com>
-Date: Fri, 30 Nov 2018 11:52:14 -0500
-Subject: btrfs: run delayed items before dropping the snapshot
-
-From: Josef Bacik <jbacik@fb.com>
-
-commit 0568e82dbe2510fc1fa664f58e5c997d3f1e649e upstream.
-
-With my delayed refs patches in place we started seeing a large amount
-of aborts in __btrfs_free_extent:
-
- BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root 35964 owner 1 offset 0
- Call Trace:
- ? btrfs_merge_delayed_refs+0xaf/0x340
- __btrfs_run_delayed_refs+0x6ea/0xfc0
- ? btrfs_set_path_blocking+0x31/0x60
- btrfs_run_delayed_refs+0xeb/0x180
- btrfs_commit_transaction+0x179/0x7f0
- ? btrfs_check_space_for_delayed_refs+0x30/0x50
- ? should_end_transaction.isra.19+0xe/0x40
- btrfs_drop_snapshot+0x41c/0x7c0
- btrfs_clean_one_deleted_snapshot+0xb5/0xd0
- cleaner_kthread+0xf6/0x120
- kthread+0xf8/0x130
- ? btree_invalidatepage+0x90/0x90
- ? kthread_bind+0x10/0x10
- ret_from_fork+0x35/0x40
-
-This was because btrfs_drop_snapshot depends on the root not being
-modified while it's dropping the snapshot. It will unlock the root node
-(and really every node) as it walks down the tree, only to re-lock it
-when it needs to do something. This is a problem because if we modify
-the tree we could cow a block in our path, which frees our reference to
-that block. Then once we get back to that shared block we'll free our
-reference to it again, and get ENOENT when trying to lookup our extent
-reference to that block in __btrfs_free_extent.
-
-This is ultimately happening because we have delayed items left to be
-processed for our deleted snapshot _after_ all of the inodes are closed
-for the snapshot. We only run the delayed inode item if we're deleting
-the inode, and even then we do not run the delayed insertions or delayed
-removals. These can be run at any point after our final inode does its
-last iput, which is what triggers the snapshot deletion. We can end up
-with the snapshot deletion happening and then have the delayed items run
-on that file system, resulting in the above problem.
-
-This problem has existed forever, however my patches made it much easier
-to hit as I wake up the cleaner much more often to deal with delayed
-iputs, which made us more likely to start the snapshot dropping work
-before the transaction commits, which is when the delayed items would
-generally be run. Before, generally speaking, we would run the delayed
-items, commit the transaction, and wakeup the cleaner thread to start
-deleting snapshots, which means we were less likely to hit this problem.
-You could still hit it if you had multiple snapshots to be deleted and
-ended up with lots of delayed items, but it was definitely harder.
-
-Fix for now by simply running all the delayed items before starting to
-drop the snapshot. We could make this smarter in the future by making
-the delayed items per-root, and then simply drop any delayed items for
-roots that we are going to delete. But for now just a quick and easy
-solution is the safest.
-
-CC: stable@vger.kernel.org # 4.4+
-Reviewed-by: Filipe Manana <fdmanana@suse.com>
-Signed-off-by: Josef Bacik <josef@toxicpanda.com>
-Signed-off-by: David Sterba <dsterba@suse.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- fs/btrfs/extent-tree.c | 4 ++++
- 1 file changed, 4 insertions(+)
-
---- a/fs/btrfs/extent-tree.c
-+++ b/fs/btrfs/extent-tree.c
-@@ -9183,6 +9183,10 @@ int btrfs_drop_snapshot(struct btrfs_roo
- goto out_free;
- }
-
-+ err = btrfs_run_delayed_items(trans);
-+ if (err)
-+ goto out_end_trans;
-+
- if (block_rsv)
- trans->block_rsv = block_rsv;
-
cgroup-fix-css_task_iter_procs.patch
cdc-acm-fix-abnormal-data-rx-issue-for-mediatek-preloader.patch
btrfs-fix-fsync-of-files-with-multiple-hard-links-in-new-directories.patch
-btrfs-run-delayed-items-before-dropping-the-snapshot.patch
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
netfilter-xt_connlimit-don-t-store-address-in-the-co.patch
netfilter-nf_conncount-expose-connection-list-interf.patch
+++ /dev/null
-From 0568e82dbe2510fc1fa664f58e5c997d3f1e649e Mon Sep 17 00:00:00 2001
-From: Josef Bacik <jbacik@fb.com>
-Date: Fri, 30 Nov 2018 11:52:14 -0500
-Subject: btrfs: run delayed items before dropping the snapshot
-
-From: Josef Bacik <jbacik@fb.com>
-
-commit 0568e82dbe2510fc1fa664f58e5c997d3f1e649e upstream.
-
-With my delayed refs patches in place we started seeing a large amount
-of aborts in __btrfs_free_extent:
-
- BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root 35964 owner 1 offset 0
- Call Trace:
- ? btrfs_merge_delayed_refs+0xaf/0x340
- __btrfs_run_delayed_refs+0x6ea/0xfc0
- ? btrfs_set_path_blocking+0x31/0x60
- btrfs_run_delayed_refs+0xeb/0x180
- btrfs_commit_transaction+0x179/0x7f0
- ? btrfs_check_space_for_delayed_refs+0x30/0x50
- ? should_end_transaction.isra.19+0xe/0x40
- btrfs_drop_snapshot+0x41c/0x7c0
- btrfs_clean_one_deleted_snapshot+0xb5/0xd0
- cleaner_kthread+0xf6/0x120
- kthread+0xf8/0x130
- ? btree_invalidatepage+0x90/0x90
- ? kthread_bind+0x10/0x10
- ret_from_fork+0x35/0x40
-
-This was because btrfs_drop_snapshot depends on the root not being
-modified while it's dropping the snapshot. It will unlock the root node
-(and really every node) as it walks down the tree, only to re-lock it
-when it needs to do something. This is a problem because if we modify
-the tree we could cow a block in our path, which frees our reference to
-that block. Then once we get back to that shared block we'll free our
-reference to it again, and get ENOENT when trying to lookup our extent
-reference to that block in __btrfs_free_extent.
-
-This is ultimately happening because we have delayed items left to be
-processed for our deleted snapshot _after_ all of the inodes are closed
-for the snapshot. We only run the delayed inode item if we're deleting
-the inode, and even then we do not run the delayed insertions or delayed
-removals. These can be run at any point after our final inode does its
-last iput, which is what triggers the snapshot deletion. We can end up
-with the snapshot deletion happening and then have the delayed items run
-on that file system, resulting in the above problem.
-
-This problem has existed forever, however my patches made it much easier
-to hit as I wake up the cleaner much more often to deal with delayed
-iputs, which made us more likely to start the snapshot dropping work
-before the transaction commits, which is when the delayed items would
-generally be run. Before, generally speaking, we would run the delayed
-items, commit the transaction, and wakeup the cleaner thread to start
-deleting snapshots, which means we were less likely to hit this problem.
-You could still hit it if you had multiple snapshots to be deleted and
-ended up with lots of delayed items, but it was definitely harder.
-
-Fix for now by simply running all the delayed items before starting to
-drop the snapshot. We could make this smarter in the future by making
-the delayed items per-root, and then simply drop any delayed items for
-roots that we are going to delete. But for now just a quick and easy
-solution is the safest.
-
-CC: stable@vger.kernel.org # 4.4+
-Reviewed-by: Filipe Manana <fdmanana@suse.com>
-Signed-off-by: Josef Bacik <josef@toxicpanda.com>
-Signed-off-by: David Sterba <dsterba@suse.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- fs/btrfs/extent-tree.c | 4 ++++
- 1 file changed, 4 insertions(+)
-
---- a/fs/btrfs/extent-tree.c
-+++ b/fs/btrfs/extent-tree.c
-@@ -9252,6 +9252,10 @@ int btrfs_drop_snapshot(struct btrfs_roo
- goto out_free;
- }
-
-+ err = btrfs_run_delayed_items(trans);
-+ if (err)
-+ goto out_end_trans;
-+
- if (block_rsv)
- trans->block_rsv = block_rsv;
-
clk-rockchip-fix-typo-in-rk3188-spdif_frac-parent.patch
cdc-acm-fix-abnormal-data-rx-issue-for-mediatek-preloader.patch
btrfs-fix-fsync-of-files-with-multiple-hard-links-in-new-directories.patch
-btrfs-run-delayed-items-before-dropping-the-snapshot.patch
powerpc-tm-set-msr-just-prior-to-recheckpoint.patch
f2fs-fix-validation-of-the-block-count-in-sanity_check_raw_super.patch
serial-uartps-fix-interrupt-mask-issue-to-handle-the-rx-interrupts-properly.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
