December 2024 - Linux-stable-mirror

btrfs: lsblk multiple mount point issue on LTS 6.6

by Mike Pagano

Greg, A Gentoo user found an issue with btrfs where: "... upstream commit a5d74fa24752 ("btrfs: avoid unnecessary device path update for the same device") breaks 6.6 LTS kernel behavior where previously lsblk can properly show multiple mount points of the same btrfs" There's a revert on the bug report [1]. The fix by the author can be found on linux-btrfs [2] [1] https://bugs.gentoo.org/947126 [2] https://lore.kernel.org/linux-btrfs/30aefd8b4e8c1f0c5051630b106a1ff3570d28e… Mike -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpagano(a)gentoo.org GnuPG FP : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137 Public Key : http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index

6 months

2
1
0 0

[PATCH v2 1/2] fs/proc: do_task_stat: Fix ESP not readable during coredump

by Nam Cao

The field "eip" (instruction pointer) and "esp" (stack pointer) of a task can be read from /proc/PID/stat. These fields can be interesting for coredump. However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat"), because it is generally unsafe to do so. But it is safe for a coredumping process, and therefore exceptions were made: - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping"). - for all other threads in a coredumping process by commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads"). The above two commits check the PF_DUMPCORE flag to determine a coredump thread and the PF_EXITING flag for the other threads. Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") moved coredump to happen earlier and before PF_EXITING is set. Thus, checking PF_EXITING is no longer the correct way to determine threads in a coredumping process. Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads. Checking of PF_EXITING was added for coredumping, so it probably can now be removed. But it doesn't hurt to keep. Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Cc: stable(a)vger.kernel.org Cc: Eric W. Biederman <ebiederm(a)xmission.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Nam Cao <namcao(a)linutronix.de> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 55ed3510d2bb..d6a0369caa93 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -500,7 +500,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, * a program is not able to use ptrace(2) in that case. It is * safe because the task has stopped executing permanently. */ - if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) { + if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE|PF_POSTCOREDUMP))) { if (try_get_task_stack(task)) { eip = KSTK_EIP(task); esp = KSTK_ESP(task); -- 2.39.5

6 months

2
1
0 0

Re: [PATCH 6.12 000/114] 6.12.8-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

6 months

1
0
0 0

Re: Patch "watchdog: s3c2410_wdt: add support for exynosautov920 SoC" has been added to the 6.12-stable tree

by Krzysztof Kozlowski

On 28/12/2024 15:20, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > watchdog: s3c2410_wdt: add support for exynosautov920 SoC > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > watchdog-s3c2410_wdt-add-support-for-exynosautov920-.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. This is a new device support, depending on several other pieces like syscon support, Exynos PMU and of course arm64/boot/dts patches. It really relies on the rest of SoC support and alone is useless. This is way beyond simple quirks thus I believe it does not meet stable criteria at all. Based on that I recommend to drop this patch from stable backports. Best regards, Krzysztof

6 months

2
1
0 0

[PATCH stable 5.15] net:dsa:fix the dsa_ptr null pointer dereference

by jiang.kun2＠zte.com.cn

From: Peilin He<he.peilin(a)zte.com.cn> Upstream commit 6c24a03a61a2 ("net: dsa: improve shutdown sequence") Issue ===== Repeatedly accessing the DSA Ethernet controller via the ethtool command, followed by a system reboot, may trigger a DSA null pointer dereference, causing a kernel panic and preventing the system from rebooting properly. This can lead to data loss or denial-of-service, resulting in serious consequences. The following is the panic log: [ 172.523467] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 172.706923] Call trace: [ 172.709371] dsa_master_get_sset_count+0x24/0xa4 [ 172.714000] ethtool_get_drvinfo+0x8c/0x210 [ 172.718193] dev_ethtool+0x780/0x2120 [ 172.721863] dev_ioctl+0x1b0/0x580 [ 172.725273] sock_do_ioctl+0xc0/0x100 [ 172.728944] sock_ioctl+0x130/0x3c0 [ 172.732440] __arm64_sys_ioctl+0xb4/0x100 [ 172.736460] invoke_syscall+0x50/0x120 [ 172.740219] el0_svc_common.constprop.0+0x4c/0xf4 [ 172.744936] do_el0_svc+0x2c/0xa0 [ 172.748257] el0_svc+0x20/0x60 [ 172.751318] el0t_64_sync_handler+0xe8/0x114 [ 172.755599] el0t_64_sync+0x180/0x184 [ 172.759271] Code: a90153f3 2a0103f4 a9025bf5 f9418015 (f94012b6) [ 172.765383] ---[ end trace 0000000000000002 ]--- Root Cause ========== Based on analysis of the Linux 5.15 stable version, the function dsa_master_get_sset_count() accesses members of the structure pointed to by cpu_dp without checking for a null pointer. If cpu_dp is a null pointer, this will cause a kernel panic. static int dsa_master_get_sset_count(struct net_device *dev, int sset) { struct dsa_port *cpu_dp = dev->dsa_ptr; const struct ethtool_ops *ops = cpu_dp->orig_ethtool_ops; struct dsa_switch *ds = cpu_dp->ds; ... } dev->dsa_ptr is set to NULL in the dsa_switch_shutdown() or dsa_master_teardown() functions. When the DSA module unloads, dsa_master_ethtool_teardown(dev) restores the original copy of the DSA device's ethtool_ops using "dev->ethtool_ops = cpu_dp->orig_ethtool_ops;" before setting dev->dsa_ptr to NULL. This ensures that ethtool_ops remains accessible after DSA unloads. However, dsa_switch_shutdown does not restore the original copy of the DSA device's ethtool_ops, potentially leading to a null pointer dereference of dsa_ptr and causing a system panic. Essentially, when we set master->dsa_ptr to NULL, we need to ensure that no user ports are making requests to the DSA driver. Solution ======== The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. Fixes: ee534378f005 ("net: dsa: fix panic when DSA master device unbinds on shutdown") Suggested-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Signed-off-by: Peilin He <he.peilin(a)zte.com.cn> Reviewed-by: xu xin <xu.xin16(a)zte.com.cn> Signed-off-by: Kun Jiang <jiang.kun2(a)zte.com.cn> Cc: Fan Yu <fan.yu9(a)zte.com.cn> Cc: Yutan Qiu <qiu.yutan(a)zte.com.cn> Cc: Yaxin Wang <wang.yaxin(a)zte.com.cn> Cc: tuqiang <tu.qiang35(a)zte.com.cn> Cc: Yang Yang <yang.yang29(a)zte.com.cn> Cc: ye xingchen <ye.xingchen(a)zte.com.cn> Cc: Yunkai Zhang <zhang.yunkai(a)zte.com.cn> --- net/dsa/dsa2.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c index 543834e31298..bf384b30ec0a 100644 --- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -1656,6 +1656,7 @@ EXPORT_SYMBOL_GPL(dsa_unregister_switch); void dsa_switch_shutdown(struct dsa_switch *ds) { struct net_device *master, *slave_dev; + LIST_HEAD(close_list); struct dsa_port *dp; mutex_lock(&dsa2_mutex); @@ -1665,6 +1666,11 @@ void dsa_switch_shutdown(struct dsa_switch *ds) rtnl_lock(); + dsa_switch_for_each_cpu_port(dp, ds) + list_add(&dp->master->close_list, &close_list); + + dev_close_many(&close_list, true); + list_for_each_entry(dp, &ds->dst->ports, list) { if (dp->ds != ds) continue; @@ -1675,6 +1681,7 @@ void dsa_switch_shutdown(struct dsa_switch *ds) master = dp->cpu_dp->master; slave_dev = dp->slave; + netif_device_detach(slave_dev); netdev_upper_dev_unlink(master, slave_dev); } -- 2.25.1

6 months

2
1
0 0

[PATCH 6/6] nvmem: core: improve range check for nvmem_cell_write()

by srinivas.kandagatla＠linaro.org

From: Jennifer Berringer <jberring(a)redhat.com> When __nvmem_cell_entry_write() is called for an nvmem cell that does not need bit shifting, it requires that the len parameter exactly matches the nvmem cell size. However, when the nvmem cell has a nonzero bit_offset, it was skipping this check. Accepting values of len larger than the cell size results in nvmem_cell_prepare_write_buffer() trying to write past the end of a heap buffer that it allocates. Add a check to avoid that problem and instead return -EINVAL when len doesn't match the number of bits expected by the nvmem cell when bit_offset is nonzero. This check uses cell->nbits in order to allow providing the smaller size to cells that are shifted into another byte by bit_offset. For example, a cell with nbits=8 and nonzero bit_offset would have bytes=2 but should accept a 1-byte write here, although no current callers depend on this. Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: stable(a)vger.kernel.org Signed-off-by: Jennifer Berringer <jberring(a)redhat.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index d6494dfc20a7..845540b57e68 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -1790,6 +1790,8 @@ static int __nvmem_cell_entry_write(struct nvmem_cell_entry *cell, void *buf, si return -EINVAL; if (cell->bit_offset || cell->nbits) { + if (len != BITS_TO_BYTES(cell->nbits) && len != cell->bytes) + return -EINVAL; buf = nvmem_cell_prepare_write_buffer(cell, buf, len); if (IS_ERR(buf)) return PTR_ERR(buf); -- 2.25.1

6 months

1
0
0 0

[PATCH 5/6] nvmem: qcom-spmi-sdam: Set size in struct nvmem_config

by srinivas.kandagatla＠linaro.org

From: Luca Weiss <luca.weiss(a)fairphone.com> Let the nvmem core know what size the SDAM is, most notably this fixes the size of /sys/bus/nvmem/devices/spmi_sdam*/nvmem being '0' and makes user space work with that file. ~ # hexdump -C -s 64 /sys/bus/nvmem/devices/spmi_sdam2/nvmem 00000040 02 01 00 00 04 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 Fixes: 40ce9798794f ("nvmem: add QTI SDAM driver") Cc: stable(a)vger.kernel.org Signed-off-by: Luca Weiss <luca.weiss(a)fairphone.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy(a)linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/nvmem/qcom-spmi-sdam.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvmem/qcom-spmi-sdam.c b/drivers/nvmem/qcom-spmi-sdam.c index 9aa8f42faa4c..4f1cca6eab71 100644 --- a/drivers/nvmem/qcom-spmi-sdam.c +++ b/drivers/nvmem/qcom-spmi-sdam.c @@ -144,6 +144,7 @@ static int sdam_probe(struct platform_device *pdev) sdam->sdam_config.owner = THIS_MODULE; sdam->sdam_config.add_legacy_fixed_of_cells = true; sdam->sdam_config.stride = 1; + sdam->sdam_config.size = sdam->size; sdam->sdam_config.word_size = 1; sdam->sdam_config.reg_read = sdam_read; sdam->sdam_config.reg_write = sdam_write; -- 2.25.1

6 months

1
0
0 0

Request to backport fixes for crash in hci_unregister_dev() to 6.12.y

by Fedor Pchelkin

On 6.12 there is a kernel crash during the release of btusb Mediatek device. list_del corruption, ffff8aae1f024000->next is LIST_POISON1 (dead000000000100) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 UID: 0 PID: 3770 Comm: qemu-system-x86 Tainted: G W 6.12.5-200.fc41.x86_64 #1 Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__list_del_entry_valid_or_report.cold+0x5c/0x6f Call Trace: <TASK> hci_unregister_dev+0x46/0x1f0 [bluetooth] btusb_disconnect+0x67/0x170 [btusb] usb_unbind_interface+0x95/0x2d0 device_release_driver_internal+0x19c/0x200 proc_ioctl+0x1be/0x230 usbdev_ioctl+0x6bd/0x1430 __x64_sys_ioctl+0x91/0xd0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Note: Taint is due to the amdgpu warnings, totally unrelated to the issue. The bug has been fixed "silently" in upstream with the following series of 4 commits [1]: ad0c6f603bb0 ("Bluetooth: btusb: mediatek: move Bluetooth power off command position") cea1805f165c ("Bluetooth: btusb: mediatek: add callback function in btusb_disconnect") 489304e67087 ("Bluetooth: btusb: mediatek: add intf release flow when usb disconnect") defc33b5541e ("Bluetooth: btusb: mediatek: change the conditions for ISO interface") These commits can be cleanly cherry-picked to 6.12.y and I may confirm they fix the problem. FWIW, the offending commit is ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") and it is present in 6.11.y and 6.12.y. 6.11.y is EOL, so please apply the patches to 6.12.y. [1]: https://lore.kernel.org/linux-bluetooth/20240923084705.14123-1-chris.lu@med… -- Thanks, Fedor

6 months

2
1
0 0

FAILED: patch "[PATCH] btrfs: allow swap activation to be interruptible" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

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 9a45022a0efadd99bcc58f7f1cc2b6fb3b808c40 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024123039-broadside-tuesday-404a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9a45022a0efadd99bcc58f7f1cc2b6fb3b808c40 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Mon, 9 Dec 2024 16:31:41 +0000 Subject: [PATCH] btrfs: allow swap activation to be interruptible During swap activation we iterate over the extents of a file, then do several checks for each extent, some of which may take some significant time such as checking if an extent is shared. Since a file can have many thousands of extents, this can be a very slow operation and it's currently not interruptible. I had a bug during development of a previous patch that resulted in an infinite loop when iterating the extents, so a core was busy looping and I couldn't cancel the operation, which is very annoying and requires a reboot. So make the loop interruptible by checking for fatal signals at the end of each iteration and stopping immediately if there is one. 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> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index b87f19630b00..c4675f4345fd 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -10073,6 +10073,11 @@ static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file, bsi.block_start = physical_block_start; bsi.block_len = len; } + + if (fatal_signal_pending(current)) { + ret = -EINTR; + goto out; + } } if (bsi.block_len)

6 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: allow swap activation to be interruptible" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

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 9a45022a0efadd99bcc58f7f1cc2b6fb3b808c40 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024123040-crablike-vision-ad10@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9a45022a0efadd99bcc58f7f1cc2b6fb3b808c40 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Mon, 9 Dec 2024 16:31:41 +0000 Subject: [PATCH] btrfs: allow swap activation to be interruptible During swap activation we iterate over the extents of a file, then do several checks for each extent, some of which may take some significant time such as checking if an extent is shared. Since a file can have many thousands of extents, this can be a very slow operation and it's currently not interruptible. I had a bug during development of a previous patch that resulted in an infinite loop when iterating the extents, so a core was busy looping and I couldn't cancel the operation, which is very annoying and requires a reboot. So make the loop interruptible by checking for fatal signals at the end of each iteration and stopping immediately if there is one. 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> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index b87f19630b00..c4675f4345fd 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -10073,6 +10073,11 @@ static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file, bsi.block_start = physical_block_start; bsi.block_len = len; } + + if (fatal_signal_pending(current)) { + ret = -EINTR; + goto out; + } } if (bsi.block_len)

6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024