From: Greg Kroah-Hartman Date: Sun, 21 Aug 2022 13:58:14 +0000 (+0200) Subject: 5.19-stable patches X-Git-Tag: v4.9.326~80 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d3a4dea45b151cd674d64b449bf07aa45af78dc6;p=thirdparty%2Fkernel%2Fstable-queue.git 5.19-stable patches added patches: btrfs-fix-lost-error-handling-when-looking-up-extended-ref-on-log-replay.patch btrfs-fix-warning-during-log-replay-when-bumping-inode-link-count.patch btrfs-reset-ro-counter-on-block-group-if-we-fail-to-relocate.patch btrfs-unset-reloc-control-if-transaction-commit-fails-in-prepare_to_relocate.patch mmc-meson-gx-fix-an-error-handling-path-in-meson_mmc_probe.patch mmc-pxamci-fix-an-error-handling-path-in-pxamci_probe.patch mmc-pxamci-fix-another-error-handling-path-in-pxamci_probe.patch --- diff --git a/queue-5.19/btrfs-fix-lost-error-handling-when-looking-up-extended-ref-on-log-replay.patch b/queue-5.19/btrfs-fix-lost-error-handling-when-looking-up-extended-ref-on-log-replay.patch new file mode 100644 index 00000000000..81f58427e44 --- /dev/null +++ b/queue-5.19/btrfs-fix-lost-error-handling-when-looking-up-extended-ref-on-log-replay.patch @@ -0,0 +1,43 @@ +From 7a6b75b79902e47f46328b57733f2604774fa2d9 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Mon, 1 Aug 2022 14:57:51 +0100 +Subject: btrfs: fix lost error handling when looking up extended ref on log replay + +From: Filipe Manana + +commit 7a6b75b79902e47f46328b57733f2604774fa2d9 upstream. + +During log replay, when processing inode references, if we get an error +when looking up for an extended reference at __add_inode_ref(), we ignore +it and proceed, returning success (0) if no other error happens after the +lookup. This is obviously wrong because in case an extended reference +exists and it encodes some name not in the log, we need to unlink it, +otherwise the filesystem state will not match the state it had after the +last fsync. + +So just make __add_inode_ref() return an error it gets from the extended +reference lookup. + +Fixes: f186373fef005c ("btrfs: extended inode refs") +CC: stable@vger.kernel.org # 4.9+ +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/tree-log.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -1146,7 +1146,9 @@ again: + extref = btrfs_lookup_inode_extref(NULL, root, path, name, namelen, + inode_objectid, parent_objectid, 0, + 0); +- if (!IS_ERR_OR_NULL(extref)) { ++ if (IS_ERR(extref)) { ++ return PTR_ERR(extref); ++ } else if (extref) { + u32 item_size; + u32 cur_offset = 0; + unsigned long base; diff --git a/queue-5.19/btrfs-fix-warning-during-log-replay-when-bumping-inode-link-count.patch b/queue-5.19/btrfs-fix-warning-during-log-replay-when-bumping-inode-link-count.patch new file mode 100644 index 00000000000..3140b273091 --- /dev/null +++ b/queue-5.19/btrfs-fix-warning-during-log-replay-when-bumping-inode-link-count.patch @@ -0,0 +1,94 @@ +From 769030e11847c5412270c0726ff21d3a1f0a3131 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Mon, 1 Aug 2022 14:57:52 +0100 +Subject: btrfs: fix warning during log replay when bumping inode link count + +From: Filipe Manana + +commit 769030e11847c5412270c0726ff21d3a1f0a3131 upstream. + +During log replay, at add_link(), we may increment the link count of +another inode that has a reference that conflicts with a new reference +for the inode currently being processed. + +During log replay, at add_link(), we may drop (unlink) a reference from +some inode in the subvolume tree if that reference conflicts with a new +reference found in the log for the inode we are currently processing. + +After the unlink, If the link count has decreased from 1 to 0, then we +increment the link count to prevent the inode from being deleted if it's +evicted by an iput() call, because we may have references to add to that +inode later on (and we will fixup its link count later during log replay). + +However incrementing the link count from 0 to 1 triggers a warning: + + $ cat fs/inode.c + (...) + void inc_nlink(struct inode *inode) + { + if (unlikely(inode->i_nlink == 0)) { + WARN_ON(!(inode->i_state & I_LINKABLE)); + atomic_long_dec(&inode->i_sb->s_remove_count); + } + (...) + +The I_LINKABLE flag is only set when creating an O_TMPFILE file, so it's +never set during log replay. + +Most of the time, the warning isn't triggered even if we dropped the last +reference of the conflicting inode, and this is because: + +1) The conflicting inode was previously marked for fixup, through a call + to link_to_fixup_dir(), which increments the inode's link count; + +2) And the last iput() on the inode has not triggered eviction of the + inode, nor was eviction triggered after the iput(). So at add_link(), + even if we unlink the last reference of the inode, its link count ends + up being 1 and not 0. + +So this means that if eviction is triggered after link_to_fixup_dir() is +called, at add_link() we will read the inode back from the subvolume tree +and have it with a correct link count, matching the number of references +it has on the subvolume tree. So if when we are at add_link() the inode +has exactly one reference only, its link count is 1, and after the unlink +its link count becomes 0. + +So fix this by using set_nlink() instead of inc_nlink(), as the former +accepts a transition from 0 to 1 and it's what we use in other similar +contexts (like at link_to_fixup_dir(). + +Also make add_inode_ref() use set_nlink() instead of inc_nlink() to +bump the link count from 0 to 1. + +The warning is actually harmless, but it may scare users. Josef also ran +into it recently. + +CC: stable@vger.kernel.org # 5.1+ +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/tree-log.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -1459,7 +1459,7 @@ static int add_link(struct btrfs_trans_h + * on the inode will not free it. We will fixup the link count later. + */ + if (other_inode->i_nlink == 0) +- inc_nlink(other_inode); ++ set_nlink(other_inode, 1); + add_link: + ret = btrfs_add_link(trans, BTRFS_I(dir), BTRFS_I(inode), + name, namelen, 0, ref_index); +@@ -1602,7 +1602,7 @@ static noinline int add_inode_ref(struct + * free it. We will fixup the link count later. + */ + if (!ret && inode->i_nlink == 0) +- inc_nlink(inode); ++ set_nlink(inode, 1); + } + if (ret < 0) + goto out; diff --git a/queue-5.19/btrfs-reset-ro-counter-on-block-group-if-we-fail-to-relocate.patch b/queue-5.19/btrfs-reset-ro-counter-on-block-group-if-we-fail-to-relocate.patch new file mode 100644 index 00000000000..3f3fb1f3302 --- /dev/null +++ b/queue-5.19/btrfs-reset-ro-counter-on-block-group-if-we-fail-to-relocate.patch @@ -0,0 +1,45 @@ +From 74944c873602a3ed8d16ff7af3f64af80c0f9dac Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Mon, 25 Jul 2022 13:05:05 -0400 +Subject: btrfs: reset RO counter on block group if we fail to relocate + +From: Josef Bacik + +commit 74944c873602a3ed8d16ff7af3f64af80c0f9dac upstream. + +With the automatic block group reclaim code we will preemptively try to +mark the block group RO before we start the relocation. We do this to +make sure we should actually try to relocate the block group. + +However if we hit an error during the actual relocation we won't clean +up our RO counter and the block group will remain RO. This was observed +internally with file systems reporting less space available from df when +we had failed background relocations. + +Fix this by doing the dec_ro in the error case. + +Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Boris Burkov +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/block-group.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -1640,9 +1640,11 @@ void btrfs_reclaim_bgs_work(struct work_ + div64_u64(zone_unusable * 100, bg->length)); + trace_btrfs_reclaim_block_group(bg); + ret = btrfs_relocate_chunk(fs_info, bg->start); +- if (ret) ++ if (ret) { ++ btrfs_dec_block_group_ro(bg); + btrfs_err(fs_info, "error relocating chunk %llu", + bg->start); ++ } + + next: + btrfs_put_block_group(bg); diff --git a/queue-5.19/btrfs-unset-reloc-control-if-transaction-commit-fails-in-prepare_to_relocate.patch b/queue-5.19/btrfs-unset-reloc-control-if-transaction-commit-fails-in-prepare_to_relocate.patch new file mode 100644 index 00000000000..0f5ee45aaff --- /dev/null +++ b/queue-5.19/btrfs-unset-reloc-control-if-transaction-commit-fails-in-prepare_to_relocate.patch @@ -0,0 +1,102 @@ +From 85f02d6c856b9f3a0acf5219de6e32f58b9778eb Mon Sep 17 00:00:00 2001 +From: Zixuan Fu +Date: Thu, 21 Jul 2022 15:48:29 +0800 +Subject: btrfs: unset reloc control if transaction commit fails in prepare_to_relocate() + +From: Zixuan Fu + +commit 85f02d6c856b9f3a0acf5219de6e32f58b9778eb upstream. + +In btrfs_relocate_block_group(), the rc is allocated. Then +btrfs_relocate_block_group() calls + +relocate_block_group() + prepare_to_relocate() + set_reloc_control() + +that assigns rc to the variable fs_info->reloc_ctl. When +prepare_to_relocate() returns, it calls + +btrfs_commit_transaction() + btrfs_start_dirty_block_groups() + btrfs_alloc_path() + kmem_cache_zalloc() + +which may fail for example (or other errors could happen). When the +failure occurs, btrfs_relocate_block_group() detects the error and frees +rc and doesn't set fs_info->reloc_ctl to NULL. After that, in +btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and +then used, which may cause a use-after-free bug. + +This possible bug can be triggered by calling btrfs_ioctl_balance() +before calling btrfs_ioctl_defrag(). + +To fix this possible bug, in prepare_to_relocate(), check if +btrfs_commit_transaction() fails. If the failure occurs, +unset_reloc_control() is called to set fs_info->reloc_ctl to NULL. + +The error log in our fault-injection testing is shown as follows: + + [ 58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs] + ... + [ 58.753577] Call Trace: + ... + [ 58.755800] kasan_report+0x45/0x60 + [ 58.756066] btrfs_init_reloc_root+0x7ca/0x920 [btrfs] + [ 58.757304] record_root_in_trans+0x792/0xa10 [btrfs] + [ 58.757748] btrfs_record_root_in_trans+0x463/0x4f0 [btrfs] + [ 58.758231] start_transaction+0x896/0x2950 [btrfs] + [ 58.758661] btrfs_defrag_root+0x250/0xc00 [btrfs] + [ 58.759083] btrfs_ioctl_defrag+0x467/0xa00 [btrfs] + [ 58.759513] btrfs_ioctl+0x3c95/0x114e0 [btrfs] + ... + [ 58.768510] Allocated by task 23683: + [ 58.768777] ____kasan_kmalloc+0xb5/0xf0 + [ 58.769069] __kmalloc+0x227/0x3d0 + [ 58.769325] alloc_reloc_control+0x10a/0x3d0 [btrfs] + [ 58.769755] btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs] + [ 58.770228] btrfs_relocate_chunk+0xf1/0x760 [btrfs] + [ 58.770655] __btrfs_balance+0x1326/0x1f10 [btrfs] + [ 58.771071] btrfs_balance+0x3150/0x3d30 [btrfs] + [ 58.771472] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] + [ 58.771902] btrfs_ioctl+0x4caa/0x114e0 [btrfs] + ... + [ 58.773337] Freed by task 23683: + ... + [ 58.774815] kfree+0xda/0x2b0 + [ 58.775038] free_reloc_control+0x1d6/0x220 [btrfs] + [ 58.775465] btrfs_relocate_block_group+0x115c/0x1e20 [btrfs] + [ 58.775944] btrfs_relocate_chunk+0xf1/0x760 [btrfs] + [ 58.776369] __btrfs_balance+0x1326/0x1f10 [btrfs] + [ 58.776784] btrfs_balance+0x3150/0x3d30 [btrfs] + [ 58.777185] btrfs_ioctl_balance+0xd84/0x1410 [btrfs] + [ 58.777621] btrfs_ioctl+0x4caa/0x114e0 [btrfs] + ... + +Reported-by: TOTE Robot +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Sweet Tea Dorminy +Reviewed-by: Nikolay Borisov +Signed-off-by: Zixuan Fu +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/relocation.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -3573,7 +3573,12 @@ int prepare_to_relocate(struct reloc_con + */ + return PTR_ERR(trans); + } +- return btrfs_commit_transaction(trans); ++ ++ ret = btrfs_commit_transaction(trans); ++ if (ret) ++ unset_reloc_control(rc); ++ ++ return ret; + } + + static noinline_for_stack int relocate_block_group(struct reloc_control *rc) diff --git a/queue-5.19/mmc-meson-gx-fix-an-error-handling-path-in-meson_mmc_probe.patch b/queue-5.19/mmc-meson-gx-fix-an-error-handling-path-in-meson_mmc_probe.patch new file mode 100644 index 00000000000..39da0203f67 --- /dev/null +++ b/queue-5.19/mmc-meson-gx-fix-an-error-handling-path-in-meson_mmc_probe.patch @@ -0,0 +1,38 @@ +From b3e1cf31154136da855f3cb6117c17eb0b6bcfb4 Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sun, 7 Aug 2022 08:56:38 +0200 +Subject: mmc: meson-gx: Fix an error handling path in meson_mmc_probe() + +From: Christophe JAILLET + +commit b3e1cf31154136da855f3cb6117c17eb0b6bcfb4 upstream. + +The commit in Fixes has introduced a new error handling which should goto +the existing error handling path. +Otherwise some resources leak. + +Fixes: 19c6beaa064c ("mmc: meson-gx: add device reset") +Signed-off-by: Christophe JAILLET +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/be4b863bacf323521ba3a02efdc4fca9cdedd1a6.1659855351.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/meson-gx-mmc.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/meson-gx-mmc.c ++++ b/drivers/mmc/host/meson-gx-mmc.c +@@ -1172,8 +1172,10 @@ static int meson_mmc_probe(struct platfo + } + + ret = device_reset_optional(&pdev->dev); +- if (ret) +- return dev_err_probe(&pdev->dev, ret, "device reset failed\n"); ++ if (ret) { ++ dev_err_probe(&pdev->dev, ret, "device reset failed\n"); ++ goto free_host; ++ } + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + host->regs = devm_ioremap_resource(&pdev->dev, res); diff --git a/queue-5.19/mmc-pxamci-fix-an-error-handling-path-in-pxamci_probe.patch b/queue-5.19/mmc-pxamci-fix-an-error-handling-path-in-pxamci_probe.patch new file mode 100644 index 00000000000..1a97010d170 --- /dev/null +++ b/queue-5.19/mmc-pxamci-fix-an-error-handling-path-in-pxamci_probe.patch @@ -0,0 +1,35 @@ +From 98d7c5e5792b8ce3e1352196dac7f404bb1b46ec Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Tue, 26 Jul 2022 21:15:43 +0200 +Subject: mmc: pxamci: Fix an error handling path in pxamci_probe() + +From: Christophe JAILLET + +commit 98d7c5e5792b8ce3e1352196dac7f404bb1b46ec upstream. + +The commit in Fixes: has moved some code around without updating gotos to +the error handling path. + +Update it now and release some resources if pxamci_of_init() fails. + +Fixes: fa3a5115469c ("mmc: pxamci: call mmc_of_parse()") +Signed-off-by: Christophe JAILLET +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/6d75855ad4e2470e9ed99e0df21bc30f0c925a29.1658862932.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/pxamci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/host/pxamci.c ++++ b/drivers/mmc/host/pxamci.c +@@ -648,7 +648,7 @@ static int pxamci_probe(struct platform_ + + ret = pxamci_of_init(pdev, mmc); + if (ret) +- return ret; ++ goto out; + + host = mmc_priv(mmc); + host->mmc = mmc; diff --git a/queue-5.19/mmc-pxamci-fix-another-error-handling-path-in-pxamci_probe.patch b/queue-5.19/mmc-pxamci-fix-another-error-handling-path-in-pxamci_probe.patch new file mode 100644 index 00000000000..05173099474 --- /dev/null +++ b/queue-5.19/mmc-pxamci-fix-another-error-handling-path-in-pxamci_probe.patch @@ -0,0 +1,35 @@ +From b886f54c300d31c109d2e4336b22922b64e7ba7d Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Tue, 26 Jul 2022 21:15:51 +0200 +Subject: mmc: pxamci: Fix another error handling path in pxamci_probe() + +From: Christophe JAILLET + +commit b886f54c300d31c109d2e4336b22922b64e7ba7d upstream. + +The commit in Fixes: has introduced an new error handling without branching +to the existing error handling path. + +Update it now and release some resources if pxamci_init_ocr() fails. + +Fixes: 61951fd6cb49 ("mmc: pxamci: let mmc core handle regulators") +Signed-off-by: Christophe JAILLET +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/07a2dcebf8ede69b484103de8f9df043f158cffd.1658862932.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/pxamci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/host/pxamci.c ++++ b/drivers/mmc/host/pxamci.c +@@ -672,7 +672,7 @@ static int pxamci_probe(struct platform_ + + ret = pxamci_init_ocr(host); + if (ret < 0) +- return ret; ++ goto out; + + mmc->caps = 0; + host->cmdat = 0; diff --git a/queue-5.19/series b/queue-5.19/series index 0b8a45fc651..3956d33fbe4 100644 --- a/queue-5.19/series +++ b/queue-5.19/series @@ -12,3 +12,10 @@ drm-amdgpu-only-disable-prefer_shadow-on-hawaii.patch drm-amd-display-check-correct-bounds-for-stream-encoder-instances-for-dcn303.patch s390-ap-fix-crash-on-older-machines-based-on-qci-info-missing.patch ata-libata-eh-add-missing-command-name.patch +mmc-pxamci-fix-another-error-handling-path-in-pxamci_probe.patch +mmc-pxamci-fix-an-error-handling-path-in-pxamci_probe.patch +mmc-meson-gx-fix-an-error-handling-path-in-meson_mmc_probe.patch +btrfs-unset-reloc-control-if-transaction-commit-fails-in-prepare_to_relocate.patch +btrfs-reset-ro-counter-on-block-group-if-we-fail-to-relocate.patch +btrfs-fix-lost-error-handling-when-looking-up-extended-ref-on-log-replay.patch +btrfs-fix-warning-during-log-replay-when-bumping-inode-link-count.patch