- Linux-stable-mirror - lists.linaro.org

[PATCH net] gve: trigger RX NAPI instead of TX NAPI in gve_xsk_wakeup

by Praveen Kaligineedi

From: Joshua Washington <joshwash(a)google.com> Commit ba0925c34e0f ("gve: process XSK TX descriptors as part of RX NAPI") moved XSK TX processing to be part of the RX NAPI. However, that commit did not include triggering the RX NAPI in gve_xsk_wakeup. This is necessary because the TX NAPI only processes TX completions, meaning that a TX wakeup would not actually trigger XSK descriptor processing. Also, the branch on XDP_WAKEUP_TX was supposed to have been removed, as the NAPI should be scheduled whether the wakeup is for RX or TX. Fixes: ba0925c34e0f ("gve: process XSK TX descriptors as part of RX NAPI") Cc: stable(a)vger.kernel.org Signed-off-by: Joshua Washington <joshwash(a)google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi(a)google.com> --- drivers/net/ethernet/google/gve/gve_main.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c index 09fb7f16f73e..8a8f6ab12a98 100644 --- a/drivers/net/ethernet/google/gve/gve_main.c +++ b/drivers/net/ethernet/google/gve/gve_main.c @@ -1714,7 +1714,7 @@ static int gve_xsk_pool_disable(struct net_device *dev, static int gve_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags) { struct gve_priv *priv = netdev_priv(dev); - int tx_queue_id = gve_xdp_tx_queue_id(priv, queue_id); + struct napi_struct *napi; if (!gve_get_napi_enabled(priv)) return -ENETDOWN; @@ -1722,19 +1722,12 @@ static int gve_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags) if (queue_id >= priv->rx_cfg.num_queues || !priv->xdp_prog) return -EINVAL; - if (flags & XDP_WAKEUP_TX) { - struct gve_tx_ring *tx = &priv->tx[tx_queue_id]; - struct napi_struct *napi = - &priv->ntfy_blocks[tx->ntfy_id].napi; - - if (!napi_if_scheduled_mark_missed(napi)) { - /* Call local_bh_enable to trigger SoftIRQ processing */ - local_bh_disable(); - napi_schedule(napi); - local_bh_enable(); - } - - tx->xdp_xsk_wakeup++; + napi = &priv->ntfy_blocks[gve_rx_idx_to_ntfy(priv, queue_id)].napi; + if (!napi_if_scheduled_mark_missed(napi)) { + /* Call local_bh_enable to trigger SoftIRQ processing */ + local_bh_disable(); + napi_schedule(napi); + local_bh_enable(); } return 0; -- 2.47.1.613.gc27f4b7a9f-goog

1 month

2
1
0 0

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

1 month

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

1 month

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>

1 month

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

1 month

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

1 month

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

1 month

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

1 month

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

1 month

2
1
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)

1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror