commit 0503ea8f5ba73eb3ab13a81c1eefbaf51405385a upstream.
This was inadvertently fixed during the removal of __vma_adjust().
When __vma_adjust() is adjusting next with a negative value (pushing
vma->vm_end lower), there would be two writes to the maple tree. The
first write is unnecessary and uses all allocated nodes in the maple
state. The second write is necessary but will need to allocate nodes
since the first write has used the allocated nodes. This may be a
problem as it may not be safe to allocate at this time, such as a low
memory situation. Fix the issue by avoiding the first write and only
write the adjusted "next" VMA.
Reported-by: John Hsu <John.Hsu(a)mediatek.com>
Link: https://lore.kernel.org/lkml/9cb8c599b1d7f9c1c300d1a334d5eb70ec4d7357.camel…
Cc: stable(a)vger.kernel.org
Cc: linux-mm(a)kvack.org
Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
---
mm/mmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index b8af52db3bbe..bb2e0ff0ef61 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -767,7 +767,8 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
}
if (end != vma->vm_end) {
if (vma->vm_end > end) {
- if (!insert || (insert->vm_start != end)) {
+ if ((vma->vm_end + adjust_next != end) &&
+ (!insert || (insert->vm_start != end))) {
vma_mas_szero(&mas, end, vma->vm_end);
mas_reset(&mas);
VM_WARN_ON(insert &&
--
2.39.2
Hi Greg and Sasha,
Please consider applying the following patches to 6.4 and 6.3, they
should apply cleanly.
08f6554ff90e ("mips: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation")
a7e5eb53bf9b ("powerpc/vdso: Include CLANG_FLAGS explicitly in ldflags-y")
cff6e7f50bd3 ("kbuild: Add CLANG_FLAGS to as-instr")
43fc0a99906e ("kbuild: Add KBUILD_CPPFLAGS to as-option invocation")
feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS")
They resolve and help avoid build breakage with tip of tree clang, which
has become a little stricter in the flags that it will accept for a
particular target, which requires '--target=' to be passed along to all
invocations of $(CC). Our continuous integration does not currently show
any breakage with 6.1 and earlier; should these patches be needed there,
I will send them at a later time.
Cheers,
Nathan
Greg,
This is a fine selected set of backports from 6.4.
Patch 4 fixes a fix that was already backported to 5.15.y.
Patch 1 fixes a fix that is wanted in 5.15.y and this was the trigger
for creating this 6.1 backport series.
Leah will take care for the 5.15.y backports, but it may take some time.
None of these are relevant before 5.15.
These backpors have gone through the usual xfs review and testing.
Thanks,
Amir.
Darrick J. Wong (4):
xfs: explicitly specify cpu when forcing inodegc delayed work to run
immediately
xfs: check that per-cpu inodegc workers actually run on that cpu
xfs: disable reaping in fscounters scrub
xfs: fix xfs_inodegc_stop racing with mod_delayed_work
fs/xfs/scrub/common.c | 26 -------------------------
fs/xfs/scrub/common.h | 2 --
fs/xfs/scrub/fscounters.c | 13 ++++++-------
fs/xfs/scrub/scrub.c | 2 --
fs/xfs/scrub/scrub.h | 1 -
fs/xfs/xfs_icache.c | 40 ++++++++++++++++++++++++++++++++-------
fs/xfs/xfs_mount.h | 3 +++
fs/xfs/xfs_super.c | 3 +++
8 files changed, 45 insertions(+), 45 deletions(-)
--
2.34.1
Hello Greg,
I know you haven't formally released 4.14.321-rc1 for review yet, but our CI picked up a build issue so I thought I may as well report it in case it's useful information for you.
SHA: Linux 4.14.321-rc1 (bc1094b21392)
Failed build log: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/463572…
defconfig used: https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/-/blob/master/4…
Error log:
/builds/cip-project/cip-testing/linux-stable-rc-ci/gcc/gcc-11.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld: arch/arm/probes/kprobes/core.o: in function `jprobe_return':
/builds/cip-project/cip-testing/linux-stable-rc-ci/arch/arm/probes/kprobes/core.c:555: undefined reference to `kprobe_handler'
Makefile:1049: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Problem patch:
Reverting 1c18f6ba04d8 ("ARM: 9303/1: kprobes: avoid missing-declaration warnings") makes the problem go away.
Kind regards, Chris
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Hello I have been having problems for some time now with displaying any linux distribution with the new kernal. The only thing that can fix it are older kernals.
>
> I can't describe it very well, so I'm attaching some pictures, but it's like whenever anything happens on the screen, it pushes the upper left half up from the bottom. But it only goes to a certain extent, after that it just shakes around and jumps back a bit. Also, for example, the firefox icon is not where it is displayed, but where it should be (I tried it with touch).
>
> I think it has something to do with the framebuffer, because an usb stick with just the arch iso show the same issue in the tty.
>
> The hardware is a Huawei Matebook E 2022.
> Cpu: Intel® Core™ i5-1130G7
> Graphics: Intel® Iris® Xe
>
> Example under Manjaro that worked was with the
> linux-lqx-6.1.0.lqx2-1-x86_64.pkg.tar.zst kernal
> 22-Dec-2022 14:44 154507169
> from https://repo.blacksky3.com/x86_64/linux-lqx/old/
>
> Kernals above that Version dosent work, Example with 6.1.1-lqx1-linux-lqx:
> `
> $inxi -F
> System:
> Host: Johannes Kernel: 6.1.1-lqx1-linux-lqx arch: x86_64 bits: 64
> Desktop: GNOME v: 43.5 Distro: Manjaro Linux
> Machine:
> Type: Detachable System: HUAWEI product: DRC-WXX v: M1010
> serial:
> Mobo: HUAWEI model: DRC-WXX-PCB v: M1010 serial:
> UEFI: HUAWEI v: 1.30 date: 06/29/2022
> Battery:
> ID-1: BAT1 charge: 27.8 Wh (66.0%) condition: 42.1/42.1 Wh (100.0%)
> volts: 11.9 min: 11.5
> CPU:
> Info: quad core model: 11th Gen Intel Core i5-1130G7 bits: 64 type: MT MCP
> cache: L2: 5 MiB
> Speed (MHz): avg: 1395 min/max: 400/1801 cores: 1: 897 2: 1046 3: 962
> 4: 1801 5: 1801 6: 1801 7: 1801 8: 1052
> Graphics:
> Device-1: Intel Tiger Lake-UP4 GT2 [Iris Xe Graphics] driver: i915 v: kernel
> Display: wayland server: X.org v: 1.21.1.8 with: Xwayland v: 23.1.1
> compositor: gnome-shell driver: gpu: i915 resolution: 2560x1600~60Hz
> API: OpenGL v: 4.6 Mesa 23.0.3 renderer: Mesa Intel Xe Graphics (TGL GT2)
> Audio:
> Device-1: Intel driver: N/A
> Device-2: Intel Tiger Lake-LP Smart Sound Audio
> driver: sof-audio-pci-intel-tgl
> API: ALSA v: k6.1.1-lqx1-linux-lqx status: kernel-api
> Server-1: PulseAudio v: 16.1 status: active
> Network:
> Device-1: Intel Wi-Fi 6 AX201 driver: iwlwifi
> IF: wlp0s20f3 state: up mac: f4:b3:01:b7:c6:6d
> Bluetooth:
> Device-1: Intel AX201 Bluetooth driver: btusb type: USB
> Report: rfkill ID: hci0 state: up address: see --recommends
> Drives:
> Local Storage: total: 476.94 GiB used: 9.65 GiB (2.0%)
> ID-1: /dev/nvme0n1 model: PCIe-8 SSD 512GB size: 476.94 GiB
> Partition:
> ID-1: / size: 468.09 GiB used: 9.65 GiB (2.1%) fs: ext4 dev: /dev/nvme0n1p2
> ID-2: /boot/efi size: 299.4 MiB used: 288 KiB (0.1%) fs: vfat
> dev: /dev/nvme0n1p1
> Swap:
> Alert: No swap data was found.
> Sensors:
> System Temperatures: cpu: 35.0 C mobo: N/A
> Fan Speeds (RPM): N/A
> Info:
> Processes: 241 Uptime: 0m Memory: available: 15.42 GiB used: 1.18 GiB (7.6%)
> Shell: Zsh inxi: 3.3.27
>
> `
>
> Distros I testet:
> Ubuntu 20.04.2 results in Blackscreen/poweroff
> Fedora 38 (Bug as I mentiond)
> Manjaro (Bug as I mentiond)
> It all works fine when you start from grub2 in Rescue mode.
>
> That all is very new to me, so I am sorry if I did something wrong.
> I mean, I reported that bug first at the wrong place.. Anyway
>
> Best regreds Johannes
See Bugzilla for the full thread and attached pictures that demonstrate
this regression.
Anyway, I'm adding it to regzbot:
#regzbot introduced: v6.1..v6.4 https://bugzilla.kernel.org/show_bug.cgi?id=217666
#regzbot title: screen shakes on Intel® Iris® Xe
(also Cc'ing stable list because it also occurs on v6.1.y, but not in
v6.1 mainline).
Thanks.
--
An old man doll... just what I always wanted! - Clara
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x ede600e497b1461d06d22a7d17703d9096868bc3
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023071617-easeful-catlike-d302@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
ede600e497b1 ("btrfs: fix extent buffer leak after tree mod log failure at split_node()")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ede600e497b1461d06d22a7d17703d9096868bc3 Mon Sep 17 00:00:00 2001
From: Filipe Manana <fdmanana(a)suse.com>
Date: Thu, 8 Jun 2023 11:27:38 +0100
Subject: [PATCH] btrfs: fix extent buffer leak after tree mod log failure at
split_node()
At split_node(), if we fail to log the tree mod log copy operation, we
return without unlocking the split extent buffer we just allocated and
without decrementing the reference we own on it. Fix this by unlocking
it and decrementing the ref count before returning.
Fixes: 5de865eebb83 ("Btrfs: fix tree mod logging")
CC: stable(a)vger.kernel.org # 5.4+
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: Filipe Manana <fdmanana(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 7f7f13965fe9..8496535828de 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -3053,6 +3053,8 @@ static noinline int split_node(struct btrfs_trans_handle *trans,
ret = btrfs_tree_mod_log_eb_copy(split, c, 0, mid, c_nritems - mid);
if (ret) {
+ btrfs_tree_unlock(split);
+ free_extent_buffer(split);
btrfs_abort_transaction(trans, ret);
return ret;
}
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x ede600e497b1461d06d22a7d17703d9096868bc3
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023071616-ragweed-flyer-3ff6@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
ede600e497b1 ("btrfs: fix extent buffer leak after tree mod log failure at split_node()")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ede600e497b1461d06d22a7d17703d9096868bc3 Mon Sep 17 00:00:00 2001
From: Filipe Manana <fdmanana(a)suse.com>
Date: Thu, 8 Jun 2023 11:27:38 +0100
Subject: [PATCH] btrfs: fix extent buffer leak after tree mod log failure at
split_node()
At split_node(), if we fail to log the tree mod log copy operation, we
return without unlocking the split extent buffer we just allocated and
without decrementing the reference we own on it. Fix this by unlocking
it and decrementing the ref count before returning.
Fixes: 5de865eebb83 ("Btrfs: fix tree mod logging")
CC: stable(a)vger.kernel.org # 5.4+
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: Filipe Manana <fdmanana(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 7f7f13965fe9..8496535828de 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -3053,6 +3053,8 @@ static noinline int split_node(struct btrfs_trans_handle *trans,
ret = btrfs_tree_mod_log_eb_copy(split, c, 0, mid, c_nritems - mid);
if (ret) {
+ btrfs_tree_unlock(split);
+ free_extent_buffer(split);
btrfs_abort_transaction(trans, ret);
return ret;
}
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y
git checkout FETCH_HEAD
git cherry-pick -x a46d37012a5be1737393b8f82fd35665e4556eee
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023071638-uplifting-pentagram-4572@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^..
Possible dependencies:
a46d37012a5b ("ASoC: mediatek: mt8173: Fix snd_soc_component_initialize error path")
8c32984bc7da ("ASoC: mediatek: mt8173: Fix debugfs registration for components")
fceef72b68d6 ("ASoC: mt8173: use devm_platform_ioremap_resource() to simplify code")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a46d37012a5be1737393b8f82fd35665e4556eee Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda Delgado <ribalda(a)chromium.org>
Date: Mon, 12 Jun 2023 11:05:31 +0200
Subject: [PATCH] ASoC: mediatek: mt8173: Fix snd_soc_component_initialize
error path
If the second component fails to initialize, cleanup the first on.
Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org>
Cc: stable(a)kernel.org
Fixes: f1b5bf07365d ("ASoC: mt2701/mt8173: replace platform to component")
Signed-off-by: Ricardo Ribalda Delgado <ribalda(a)chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Link: https://lore.kernel.org/r/20230612-mt8173-fixup-v2-1-432aa99ce24d@chromium.…
Signed-off-by: Mark Brown <broonie(a)kernel.org>
diff --git a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
index f93c2ec8beb7..ff25c44070a3 100644
--- a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
+++ b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
@@ -1156,14 +1156,14 @@ static int mt8173_afe_pcm_dev_probe(struct platform_device *pdev)
comp_hdmi = devm_kzalloc(&pdev->dev, sizeof(*comp_hdmi), GFP_KERNEL);
if (!comp_hdmi) {
ret = -ENOMEM;
- goto err_pm_disable;
+ goto err_cleanup_components;
}
ret = snd_soc_component_initialize(comp_hdmi,
&mt8173_afe_hdmi_dai_component,
&pdev->dev);
if (ret)
- goto err_pm_disable;
+ goto err_cleanup_components;
#ifdef CONFIG_DEBUG_FS
comp_hdmi->debugfs_prefix = "hdmi";
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x a46d37012a5be1737393b8f82fd35665e4556eee
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023071637-hankering-crop-89ef@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
a46d37012a5b ("ASoC: mediatek: mt8173: Fix snd_soc_component_initialize error path")
8c32984bc7da ("ASoC: mediatek: mt8173: Fix debugfs registration for components")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a46d37012a5be1737393b8f82fd35665e4556eee Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda Delgado <ribalda(a)chromium.org>
Date: Mon, 12 Jun 2023 11:05:31 +0200
Subject: [PATCH] ASoC: mediatek: mt8173: Fix snd_soc_component_initialize
error path
If the second component fails to initialize, cleanup the first on.
Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org>
Cc: stable(a)kernel.org
Fixes: f1b5bf07365d ("ASoC: mt2701/mt8173: replace platform to component")
Signed-off-by: Ricardo Ribalda Delgado <ribalda(a)chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Link: https://lore.kernel.org/r/20230612-mt8173-fixup-v2-1-432aa99ce24d@chromium.…
Signed-off-by: Mark Brown <broonie(a)kernel.org>
diff --git a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
index f93c2ec8beb7..ff25c44070a3 100644
--- a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
+++ b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
@@ -1156,14 +1156,14 @@ static int mt8173_afe_pcm_dev_probe(struct platform_device *pdev)
comp_hdmi = devm_kzalloc(&pdev->dev, sizeof(*comp_hdmi), GFP_KERNEL);
if (!comp_hdmi) {
ret = -ENOMEM;
- goto err_pm_disable;
+ goto err_cleanup_components;
}
ret = snd_soc_component_initialize(comp_hdmi,
&mt8173_afe_hdmi_dai_component,
&pdev->dev);
if (ret)
- goto err_pm_disable;
+ goto err_cleanup_components;
#ifdef CONFIG_DEBUG_FS
comp_hdmi->debugfs_prefix = "hdmi";
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y
git checkout FETCH_HEAD
git cherry-pick -x 8a4a0b2a3eaf75ca8854f856ef29690c12b2f531
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023071641-umpire-kilogram-716d@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^..
Possible dependencies:
8a4a0b2a3eaf ("btrfs: fix race between quota disable and relocation")
e804861bd4e6 ("btrfs: fix deadlock between quota disable and qgroup rescan worker")
a855fbe69229 ("btrfs: fix lockdep splat when enabling and disabling qgroups")
49e5fb46211d ("btrfs: qgroup: export qgroups in sysfs")
5958253cf65d ("btrfs: qgroup: catch reserved space leaks at unmount time")
81f7eb00ff5b ("btrfs: destroy qgroup extent records on transaction abort")
aac0023c2106 ("btrfs: move basic block_group definitions to their own header")
d7cd4dd907c1 ("Btrfs: fix sysfs warning and missing raid sysfs directories")
867363429d70 ("btrfs: migrate the delalloc space stuff to it's own home")
fb6dea26601b ("btrfs: migrate btrfs_trans_release_chunk_metadata")
6ef03debdb3d ("btrfs: migrate the delayed refs rsv code")
67f9c2209e88 ("btrfs: migrate the global_block_rsv helpers to block-rsv.c")
550fa228ee7e ("btrfs: migrate the block-rsv code to block-rsv.c")
424a47805a81 ("btrfs: stop using block_rsv_release_bytes everywhere")
fcec36224fc6 ("btrfs: cleanup the target logic in __btrfs_block_rsv_release")
fed14b323db8 ("btrfs: export __btrfs_block_rsv_release")
0b50174ad5e9 ("btrfs: export btrfs_block_rsv_add_bytes")
d12ffdd1aa4c ("btrfs: move btrfs_block_rsv definitions into it's own header")
0d9764f6d0fb ("btrfs: move reserve_metadata_bytes and supporting code to space-info.c")
5da6afeb32e9 ("btrfs: move dump_space_info to space-info.c")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 8a4a0b2a3eaf75ca8854f856ef29690c12b2f531 Mon Sep 17 00:00:00 2001
From: Filipe Manana <fdmanana(a)suse.com>
Date: Mon, 19 Jun 2023 17:21:50 +0100
Subject: [PATCH] btrfs: fix race between quota disable and relocation
If we disable quotas while we have a relocation of a metadata block group
that has extents belonging to the quota root, we can cause the relocation
to fail with -ENOENT. This is because relocation builds backref nodes for
extents of the quota root and later needs to walk the backrefs and access
the quota root - however if in between a task disables quotas, it results
in deleting the quota root from the root tree (with btrfs_del_root(),
called from btrfs_quota_disable().
This can be sporadically triggered by test case btrfs/255 from fstests:
$ ./check btrfs/255
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.4.0-rc6-btrfs-next-134+ #1 SMP PREEMPT_DYNAMIC Thu Jun 15 11:59:28 WEST 2023
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/255 6s ... _check_dmesg: something found in dmesg (see /home/fdmanana/git/hub/xfstests/results//btrfs/255.dmesg)
- output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/255.out.bad)
--- tests/btrfs/255.out 2023-03-02 21:47:53.876609426 +0000
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/255.out.bad 2023-06-16 10:20:39.267563212 +0100
@@ -1,2 +1,4 @@
QA output created by 255
+ERROR: error during balancing '/home/fdmanana/btrfs-tests/scratch_1': No such file or directory
+There may be more info in syslog - try dmesg | tail
Silence is golden
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/255.out /home/fdmanana/git/hub/xfstests/results//btrfs/255.out.bad' to see the entire diff)
Ran: btrfs/255
Failures: btrfs/255
Failed 1 of 1 tests
To fix this make the quota disable operation take the cleaner mutex, as
relocation of a block group also takes this mutex. This is also what we
do when deleting a subvolume/snapshot, we take the cleaner mutex in the
cleaner kthread (at cleaner_kthread()) and then we call btrfs_del_root()
at btrfs_drop_snapshot() while under the protection of the cleaner mutex.
Fixes: bed92eae26cc ("Btrfs: qgroup implementation and prototypes")
CC: stable(a)vger.kernel.org # 5.4+
Signed-off-by: Filipe Manana <fdmanana(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index f8735b31da16..da1f84a0eb29 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1232,12 +1232,23 @@ int btrfs_quota_disable(struct btrfs_fs_info *fs_info)
int ret = 0;
/*
- * We need to have subvol_sem write locked, to prevent races between
- * concurrent tasks trying to disable quotas, because we will unlock
- * and relock qgroup_ioctl_lock across BTRFS_FS_QUOTA_ENABLED changes.
+ * We need to have subvol_sem write locked to prevent races with
+ * snapshot creation.
*/
lockdep_assert_held_write(&fs_info->subvol_sem);
+ /*
+ * Lock the cleaner mutex to prevent races with concurrent relocation,
+ * because relocation may be building backrefs for blocks of the quota
+ * root while we are deleting the root. This is like dropping fs roots
+ * of deleted snapshots/subvolumes, we need the same protection.
+ *
+ * This also prevents races between concurrent tasks trying to disable
+ * quotas, because we will unlock and relock qgroup_ioctl_lock across
+ * BTRFS_FS_QUOTA_ENABLED changes.
+ */
+ mutex_lock(&fs_info->cleaner_mutex);
+
mutex_lock(&fs_info->qgroup_ioctl_lock);
if (!fs_info->quota_root)
goto out;
@@ -1319,6 +1330,7 @@ int btrfs_quota_disable(struct btrfs_fs_info *fs_info)
btrfs_end_transaction(trans);
else if (trans)
ret = btrfs_end_transaction(trans);
+ mutex_unlock(&fs_info->cleaner_mutex);
return ret;
}