commit b6736e03756f42186840724eb38cb412dfb547be Author: Greg Kroah-Hartman Date: Fri May 2 07:47:11 2025 +0200 Linux 6.1.136 Link: https://lore.kernel.org/r/20250429161051.743239894@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Hardik Garg Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Link: https://lore.kernel.org/r/20250501080849.930068482@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Hardik Garg Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 715b345153825b164699c8e40493469a43817f5e Author: Josh Poimboeuf Date: Mon Mar 31 21:26:36 2025 -0700 objtool: Silence more KCOV warnings, part 2 commit 55c78035a1a8dfb05f1472018ce2a651701adb7d upstream. Similar to GCOV, KCOV can leave behind dead code and undefined behavior. Warnings related to those should be ignored. The previous commit: 6b023c784204 ("objtool: Silence more KCOV warnings") ... only did so for CONFIG_CGOV_KERNEL. Also do it for CONFIG_KCOV, but for real this time. Fixes the following warning: vmlinux.o: warning: objtool: synaptics_report_mt_data: unexpected end of section .text.synaptics_report_mt_data Fixes: 6b023c784204 ("objtool: Silence more KCOV warnings") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/a44ba16e194bcbc52c1cef3d3cd9051a62622723.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503282236.UhfRsF3B-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman commit cfe7fd06a1f89c0970a85e3000399706ea28dd4c Author: Srinivas Kandagatla Date: Wed Jul 5 13:48:50 2023 +0100 ASoC: qcom: q6afe-dai: fix Display Port Playback stream name commit 4f3fcf5f6dc8ab561e152c8747fd7e502b32266c upstream. With recent changes to add more display ports did not change the Stream name in q6afe-dai. This results in below error "ASoC: Failed to add route DISPLAY_PORT_RX -> Display Port Playback(*)" and sound card fails to probe. Fix this by adding correct stream name. Fixes: 90848a2557fe ("ASoC: qcom: q6dsp: add support to more display ports") Reported-by: Amit Pundir Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20230705124850.40069-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit fbf45385e3419b8698b5e0a434847072375cfec2 Author: Rob Herring Date: Wed Mar 29 07:38:35 2023 -0500 PCI: Fix use-after-free in pci_bus_release_domain_nr() commit 30ba2d09edb5ea857a1473ae3d820911347ada62 upstream. Commit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/20230329123835.2724518-1-robh@kernel.org Link: https://lore.kernel.org/r/b529cb69-0602-9eed-fc02-2f068707a006@nvidia.com Reported-by: Jon Hunter Tested-by: Jon Hunter Signed-off-by: Rob Herring Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org # v6.2+ Cc: Pali Rohár Signed-off-by: Greg Kroah-Hartman commit 353e182012d63c08cf742fd36d7f987ba136ae2f Author: Steven Rostedt (Google) Date: Mon Dec 12 19:38:14 2022 -0500 tracing: Remove pointer (asterisk) and brackets from cpumask_t field commit fab89a09c86f948adfc7e20a7d608bd9f323bbe1 upstream. To differentiate between long arrays and cpumasks, the __cpumask() field was created. Part of the TRACE_EVENT() macros test if the type is signed or not by using the is_signed_type() macro. The __cpumask() field used the __dynamic_array() helper but because cpumask_t is a structure, it could not be used in the is_signed_type() macro as that would fail to build, so instead it passed in the pointer to cpumask_t. Unfortunately, that creates in the format file: field:__data_loc cpumask_t *[] mask; offset:36; size:4; signed:0; Which looks like an array of pointers to cpumask_t and not a cpumask_t type, which is misleading to user space parsers. Douglas Raillard pointed out that the "[]" are also misleading, as cpumask_t is not an array. Since cpumask() hasn't been created yet, and the parsers currently fail on it (but will still produce the raw output), make it be: field:__data_loc cpumask_t mask; offset:36; size:4; signed:0; Which is the correct type of the field. Then the parsers can be updated to handle this. Link: https://lore.kernel.org/lkml/6dda5e1d-9416-b55e-88f3-31d148bc925f@arm.com/ Link: https://lore.kernel.org/linux-trace-kernel/20221212193814.0e3f1e43@gandalf.local.home Cc: Masami Hiramatsu Cc: Valentin Schneider Cc: Andrew Morton Fixes: 8230f27b1ccc ("tracing: Add __cpumask to denote a trace event field that is a cpumask_t") Reported-by: Douglas Raillard Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit c8cbb6179cabba9e59fb2af695a7e923cc5fa6b8 Author: Richard Zhu Date: Mon Dec 19 15:12:21 2022 +0800 phy: freescale: imx8m-pcie: Add one missing error return commit b574baa64cf84e7793fe79f4491ae36c16e65a0b upstream. There should be one error return when fail to fetch the perst reset. Add the missing error return. Fixes: dce9edff16ee ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support") Signed-off-by: Richard Zhu Reviewed-by: Marek Vasut Link: https://lore.kernel.org/r/1671433941-2037-1-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit fc053d2df4a21af485e4903c417055b1c9dc4d02 Author: Richard Zhu Date: Mon Oct 21 11:52:41 2024 -0400 phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check commit f89263b69731e0144d275fff777ee0dd92069200 upstream. When enable initcall_debug together with higher debug level below. CONFIG_CONSOLE_LOGLEVEL_DEFAULT=9 CONFIG_CONSOLE_LOGLEVEL_QUIET=9 CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7 The initialization of i.MX8MP PCIe PHY might be timeout failed randomly. To fix this issue, adjust the sequence of the resets refer to the power up sequence listed below. i.MX8MP PCIe PHY power up sequence: /--------------------------------------------- 1.8v supply ---------/ /--------------------------------------------------- 0.8v supply ---/ ---\ /-------------------------------------------------- X REFCLK Valid Reference Clock ---/ \-------------------------------------------------- ------------------------------------------- | i_init_restn -------------- ------------------------------------ | i_cmn_rstn --------------------- ------------------------------- | o_pll_lock_done -------------------------- Logs: imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges: imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000 imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000 probe of clk_imx8mp_audiomix.reset.0 returned 0 after 1052 usecs probe of 30e20000.clock-controller returned 0 after 32971 usecs phy phy-32f00000.pcie-phy.4: phy poweron failed --> -110 probe of 30e10000.dma-controller returned 0 after 10235 usecs imx6q-pcie 33800000.pcie: waiting for PHY ready timeout! dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2) imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110 Fixes: dce9edff16ee ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support") Cc: stable@vger.kernel.org Signed-off-by: Richard Zhu Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman v2 changes: - Rebase to latest fixes branch of linux-phy git repo. - Richard's environment have problem and can't sent out patch. So I help post this fix patch. Link: https://lore.kernel.org/r/20241021155241.943665-1-Frank.Li@nxp.com Signed-off-by: Vinod Koul commit 1a9e5875c597990ae397e59ed67e4a9be4e50194 Author: Hannes Reinecke Date: Mon Apr 14 14:05:09 2025 +0200 nvme: fixup scan failure for non-ANA multipath controllers commit 26d7fb4fd4ca1180e2fa96587dea544563b4962a upstream. Commit 62baf70c3274 caused the ANA log page to be re-read, even on controllers that do not support ANA. While this should generally harmless, some controllers hang on the unsupported log page and never finish probing. Fixes: 62baf70c3274 ("nvme: re-read ANA log page after ns scan completes") Signed-off-by: Hannes Reinecke Tested-by: Srikanth Aithal [hch: more detailed commit message] Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Signed-off-by: Greg Kroah-Hartman commit 48600cbc4b5bbb51bd73f94fb70dea44662b442f Author: Thomas Bogendoerfer Date: Fri Feb 28 15:37:02 2025 +0100 MIPS: cm: Fix warning if MIPS_CM is disabled commit b73c3ccdca95c237750c981054997c71d33e09d7 upstream. Commit e27fbe16af5c ("MIPS: cm: Detect CM quirks from device tree") introduced arch/mips/include/asm/mips-cm.h:119:13: error: ‘mips_cm_update_property’ defined but not used [-Werror=unused-function] Fix this by making empty function implementation inline Fixes: e27fbe16af5c ("MIPS: cm: Detect CM quirks from device tree") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit ae43d74d458220b6622cc1e5f24790e5aeaec624 Author: Sebastian Andrzej Siewior Date: Thu Apr 24 15:03:14 2025 +0200 xdp: Reset bpf_redirect_info before running a xdp's BPF prog. Ricardo reported a KASAN discovered use after free in v6.6-stable. The syzbot starts a BPF program via xdp_test_run_batch() which assigns ri->tgt_value via dev_hash_map_redirect() and the return code isn't XDP_REDIRECT it looks like nonsense. So the output in bpf_warn_invalid_xdp_action() appears once. Then the TUN driver runs another BPF program (on the same CPU) which returns XDP_REDIRECT without setting ri->tgt_value first. It invokes bpf_trace_printk() to print four characters and obtain the required return value. This is enough to get xdp_do_redirect() invoked which then accesses the pointer in tgt_value which might have been already deallocated. This problem does not affect upstream because since commit 401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the per-CPU variable is referenced via task's task_struct and exists on the stack during NAPI callback. Therefore it is cleared once before the first invocation and remains valid within the RCU section of the NAPI callback. Instead of performing the huge backport of the commit (plus its fix ups) here is an alternative version which only resets the variable in question prior invoking the BPF program. Acked-by: Toke Høiland-Jørgensen Reported-by: Ricardo Cañuelo Navarro Closes: https://lore.kernel.org/all/20250226-20250204-kasan-slab-use-after-free-read-in-dev_map_enqueue__submit-v3-0-360efec441ba@igalia.com/ Fixes: 97f91a7cf04ff ("bpf: add bpf_redirect_map helper routine") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman commit 3aaca46e8f9d085c1fa83e780c65df34cdfb399b Author: Marek Behún Date: Tue Apr 29 12:13:03 2025 +0200 net: dsa: mv88e6xxx: enable STU methods for 6320 family commit 1428a6109b20e356188c3fb027bdb7998cc2fb98 upstream. Commit c050f5e91b47 ("net: dsa: mv88e6xxx: Fill in STU support for all supported chips") introduced STU methods, but did not add them to the 6320 family. Fix it. Fixes: c050f5e91b47 ("net: dsa: mv88e6xxx: Fill in STU support for all supported chips") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-6-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 503d67b31c9553c524eef54d1d8536836bb62eb9 Author: Marek Behún Date: Tue Apr 29 12:13:02 2025 +0200 net: dsa: mv88e6xxx: enable .port_set_policy() for 6320 family commit a2ef58e2c4aea4de166fc9832eb2b621e88c98d5 upstream. Commit f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") did not add the .port_set_policy() method for the 6320 family. Fix it. Fixes: f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-5-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9ff467ae32eff9dbccc0e029b4024db21d548706 Author: Marek Behún Date: Tue Apr 29 12:13:01 2025 +0200 net: dsa: mv88e6xxx: enable PVT for 6321 switch commit f85c69369854a43af2c5d3b3896da0908d713133 upstream. Commit f36456522168 ("net: dsa: mv88e6xxx: move PVT description in info") did not enable PVT for 6321 switch. Fix it. Fixes: f36456522168 ("net: dsa: mv88e6xxx: move PVT description in info") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-4-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dc6b55cfe76e363cf7ae6e0ced05988dba67889d Author: Marek Behún Date: Tue Apr 29 12:13:00 2025 +0200 net: dsa: mv88e6xxx: fix atu_move_port_mask for 6341 family commit 4ae01ec007716986e1a20f1285eb013cbf188830 upstream. The atu_move_port_mask for 6341 family (Topaz) is 0xf, not 0x1f. The PortVec field is 8 bits wide, not 11 as in 6390 family. Fix this. Fixes: e606ca36bbf2 ("net: dsa: mv88e6xxx: rework ATU Remove") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-3-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e873e8f7d03a2ee5b77fb1a305c782fed98e2754 Author: Jakub Kicinski Date: Thu Feb 15 06:33:46 2024 -0800 net/sched: act_mirred: don't override retval if we already lost the skb commit 166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210 upstream. If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it. Reviewed-by: Michal Swiatkowski Fixes: e5cf1baf92cb ("act_mirred: use TC_ACT_REINSERT when possible") Signed-off-by: Jakub Kicinski Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller [Minor conflict resolved due to code context change.] Signed-off-by: Jianqi Ren Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman commit 4f9f61598b19d1e68ba33239199ba85f070ca00a Author: Marek Behún Date: Tue Apr 22 11:57:18 2025 +0200 crypto: atmel-sha204a - Set hwrng quality to lowest possible commit 8006aff15516a170640239c5a8e6696c0ba18d8e upstream. According to the review by Bill Cox [1], the Atmel SHA204A random number generator produces random numbers with very low entropy. Set the lowest possible entropy for this chip just to be safe. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Fixes: da001fb651b00e1d ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: Signed-off-by: Marek Behún Acked-by: Ard Biesheuvel Reviewed-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Marek Behún commit 3a57f45b91fba0ddd5ec06e5e4fef65e7b98c696 Author: Ian Abbott Date: Tue Apr 15 13:39:01 2025 +0100 comedi: jr3_pci: Fix synchronous deletion of timer commit 44d9b3f584c59a606b521e7274e658d5b866c699 upstream. When `jr3_pci_detach()` is called during device removal, it calls `timer_delete_sync()` to stop the timer, but the timer expiry function always reschedules the timer, so the synchronization is ineffective. Call `timer_shutdown_sync()` instead. It does not matter that the timer expiry function pointer is cleared, because the device is being removed. Fixes: 07b509e6584a5 ("Staging: comedi: add jr3_pci driver") Cc: stable Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 63d956acbfe3e26aaebaf8748336c64aec9e681d Author: Dave Kleikamp Date: Thu Oct 5 09:16:14 2023 -0500 jfs: define xtree root and page independently commit a779ed754e52d582b8c0e17959df063108bd0656 upstream. In order to make array bounds checking sane, provide a separate definition of the in-inode xtree root and the external xtree page. Signed-off-by: Dave Kleikamp Tested-by: Manas Ghandat Closes: https://syzkaller.appspot.com/bug?extid=7cb897779f3c479d0615 Closes: https://syzkaller.appspot.com/bug?extid=6b1d79dad6cc6b3eef41 Closes: https://syzkaller.appspot.com/bug?extid=67f714a53ce18d5b542e Closes: https://syzkaller.appspot.com/bug?extid=e829cfdd0de521302df4 Reported-by: syzbot+7cb897779f3c479d0615@syzkaller.appspotmail.com Reported-by: syzbot+6b1d79dad6cc6b3eef41@syzkaller.appspotmail.com Reported-by: syzbot+67f714a53ce18d5b542e@syzkaller.appspotmail.com Reported-by: syzbot+e829cfdd0de521302df4@syzkaller.appspotmail.com Signed-off-by: Aditya Dutt Signed-off-by: Greg Kroah-Hartman commit 5d59fd637a8af42b211a92b2edb2474325b4d488 Author: Sergey Shtylyov Date: Sun Apr 14 11:51:39 2024 +0300 of: module: add buffer overflow check in of_modalias() commit cf7385cb26ac4f0ee6c7385960525ad534323252 upstream. In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char). Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/bbfc6be0-c687-62b6-d015-5141b93f313e@omp.ru Signed-off-by: Rob Herring Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 2fea0d6d7b5d27fbf55512d51851ba0a346ede52 Author: Tamura Dai Date: Thu Apr 17 10:16:05 2025 +0900 spi: spi-imx: Add check for spi_imx_setupxfer() [ Upstream commit 951a04ab3a2db4029debfa48d380ef834b93207e ] Add check for the return value of spi_imx_setupxfer(). spi_imx->rx and spi_imx->tx function pointer can be NULL when spi_imx_setupxfer() return error, and make NULL pointer dereference. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: 0x0 spi_imx_pio_transfer+0x50/0xd8 spi_imx_transfer_one+0x18c/0x858 spi_transfer_one_message+0x43c/0x790 __spi_pump_transfer_message+0x238/0x5d4 __spi_sync+0x2b0/0x454 spi_write_then_read+0x11c/0x200 Signed-off-by: Tamura Dai Reviewed-by: Carlos Song Link: https://patch.msgid.link/20250417011700.14436-1-kirinode0@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fc9629651badb6d05fb8b1a6552c3f326acd7d04 Author: Meir Elisha Date: Tue Apr 8 17:38:08 2025 +0300 md/raid1: Add check for missing source disk in process_checks() [ Upstream commit b7c178d9e57c8fd4238ff77263b877f6f16182ba ] During recovery/check operations, the process_checks function loops through available disks to find a 'primary' source with successfully read data. If no suitable source disk is found after checking all possibilities, the 'primary' index will reach conf->raid_disks * 2. Add an explicit check for this condition after the loop. If no source disk was found, print an error message and return early to prevent further processing without a valid primary source. Link: https://lore.kernel.org/linux-raid/20250408143808.1026534-1-meir.elisha@volumez.com Signed-off-by: Meir Elisha Suggested-and-reviewed-by: Yu Kuai Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 61b36bdc70cae4dbd08e643b35fc91e6ecd5fc4c Author: Mostafa Saleh Date: Tue Apr 15 20:33:54 2025 +0000 ubsan: Fix panic from test_ubsan_out_of_bounds [ Upstream commit 9b044614be12d78d3a93767708b8d02fb7dfa9b0 ] Running lib_ubsan.ko on arm64 (without CONFIG_UBSAN_TRAP) panics the kernel: [ 31.616546] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: test_ubsan_out_of_bounds+0x158/0x158 [test_ubsan] [ 31.646817] CPU: 3 UID: 0 PID: 179 Comm: insmod Not tainted 6.15.0-rc2 #1 PREEMPT [ 31.648153] Hardware name: linux,dummy-virt (DT) [ 31.648970] Call trace: [ 31.649345] show_stack+0x18/0x24 (C) [ 31.650960] dump_stack_lvl+0x40/0x84 [ 31.651559] dump_stack+0x18/0x24 [ 31.652264] panic+0x138/0x3b4 [ 31.652812] __ktime_get_real_seconds+0x0/0x10 [ 31.653540] test_ubsan_load_invalid_value+0x0/0xa8 [test_ubsan] [ 31.654388] init_module+0x24/0xff4 [test_ubsan] [ 31.655077] do_one_initcall+0xd4/0x280 [ 31.655680] do_init_module+0x58/0x2b4 That happens because the test corrupts other data in the stack: 400: d5384108 mrs x8, sp_el0 404: f9426d08 ldr x8, [x8, #1240] 408: f85f83a9 ldur x9, [x29, #-8] 40c: eb09011f cmp x8, x9 410: 54000301 b.ne 470 // b.any As there is no guarantee the compiler will order the local variables as declared in the module: volatile char above[4] = { }; /* Protect surrounding memory. */ volatile int arr[4]; volatile char below[4] = { }; /* Protect surrounding memory. */ There is another problem where the out-of-bound index is 5 which is larger than the extra surrounding memory for protection. So, use a struct to enforce the ordering, and fix the index to be 4. Also, remove some of the volatiles and rely on OPTIMIZER_HIDE_VAR() Signed-off-by: Mostafa Saleh Link: https://lore.kernel.org/r/20250415203354.4109415-1-smostafa@google.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit af1c735e21d9913c0ec6e6df9e96daaa1aedf3a0 Author: Breno Leitao Date: Tue Apr 1 06:47:50 2025 -0700 spi: tegra210-quad: add rate limiting and simplify timeout error message [ Upstream commit 21f4314e66ed8d40b2ee24185d1a06a07a512eb1 ] On malfunctioning hardware, timeout error messages can appear thousands of times, creating unnecessary system pressure and log bloat. This patch makes two improvements: 1. Replace dev_err() with dev_err_ratelimited() to prevent log flooding when hardware errors persist 2. Remove the redundant timeout value parameter from the error message, as 'ret' is always zero in this error path These changes reduce logging overhead while maintaining necessary error reporting for debugging purposes. Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20250401-tegra-v2-2-126c293ec047@debian.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 009847bd69ac766ebda67ac5146583a3d3cb0b49 Author: Breno Leitao Date: Tue Apr 1 06:47:49 2025 -0700 spi: tegra210-quad: use WARN_ON_ONCE instead of WARN_ON for timeouts [ Upstream commit 41c721fc093938745d116c3a21326a0ee03bb491 ] Some machines with tegra_qspi_combined_seq_xfer hardware issues generate excessive kernel warnings, severely polluting the logs: dmesg | grep -i "WARNING:.*tegra_qspi_transfer_one_message" | wc -l 94451 This patch replaces WARN_ON with WARN_ON_ONCE for timeout conditions to reduce log spam. The subsequent error message still prints on each occurrence, providing sufficient information about the failure, while the stack trace is only needed once for debugging purposes. Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20250401-tegra-v2-1-126c293ec047@debian.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 342a5dfc21ca8c288cc5d3e1db6c3ced0eb3a17f Author: Yunlong Xing Date: Mon Apr 14 11:01:59 2025 +0800 loop: aio inherit the ioprio of original request [ Upstream commit 1fdb8188c3d505452b40cdb365b1bb32be533a8e ] Set cmd->iocb.ki_ioprio to the ioprio of loop device's request. The purpose is to inherit the original request ioprio in the aio flow. Signed-off-by: Yunlong Xing Signed-off-by: Zhiguo Niu Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250414030159.501180-1-yunlong.xing@unisoc.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ddc9ef51bca3ee5009a5812a75baad56ae5ab677 Author: Fernando Fernandez Mancera Date: Tue Apr 1 11:23:03 2025 +0200 x86/i8253: Call clockevent_i8253_disable() with interrupts disabled [ Upstream commit 3940f5349b476197fb079c5aa19c9a988de64efb ] There's a lockdep false positive warning related to i8253_lock: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ... systemd-sleep/3324 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: ffffffffb2c23398 (i8253_lock){+.+.}-{2:2}, at: pcspkr_event+0x3f/0xe0 [pcspkr] ... ... which became HARDIRQ-irq-unsafe at: ... lock_acquire+0xd0/0x2f0 _raw_spin_lock+0x30/0x40 clockevent_i8253_disable+0x1c/0x60 pit_timer_init+0x25/0x50 hpet_time_init+0x46/0x50 x86_late_time_init+0x1b/0x40 start_kernel+0x962/0xa00 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xed/0xf0 common_startup_64+0x13e/0x141 ... Lockdep complains due pit_timer_init() using the lock in an IRQ-unsafe fashion, but it's a false positive, because there is no deadlock possible at that point due to init ordering: at the point where pit_timer_init() is called there is no other possible usage of i8253_lock because the system is still in the very early boot stage with no interrupts. But in any case, pit_timer_init() should disable interrupts before calling clockevent_i8253_disable() out of general principle, and to keep lockdep working even in this scenario. Use scoped_guard() for that, as suggested by Thomas Gleixner. [ mingo: Cleaned up the changelog. ] Suggested-by: Thomas Gleixner Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Ingo Molnar Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/Z-uwd4Bnn7FcCShX@gmail.com Signed-off-by: Sasha Levin commit 30e482dfb8f27d22f518695d4bcb5e7f4c6cb08a Author: Igor Pylypiv Date: Wed Mar 19 23:03:05 2025 +0000 scsi: pm80xx: Set phy_attached to zero when device is gone [ Upstream commit f7b705c238d1483f0a766e2b20010f176e5c0fb7 ] When a fatal error occurs, a phy down event may not be received to set phy->phy_attached to zero. Signed-off-by: Igor Pylypiv Signed-off-by: Salomon Dushimirimana Link: https://lore.kernel.org/r/20250319230305.3172920-1-salomondush@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dae1e15fccb521e8295422cb68985e3ed2406f77 Author: Peter Griffin Date: Wed Mar 19 15:30:18 2025 +0000 scsi: ufs: exynos: Ensure pre_link() executes before exynos_ufs_phy_init() [ Upstream commit 3d101165e72316775947d71321d97194f03dfef3 ] Ensure clocks are enabled before configuring unipro. Additionally move the pre_link() hook before the exynos_ufs_phy_init() calls. This means the register write sequence more closely resembles the ordering of the downstream driver. Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20250319-exynos-ufs-stability-fixes-v2-1-96722cc2ba1b@linaro.org Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9e3014d786464b9df7bb7c3f54f205f593761349 Author: Xingui Yang Date: Wed Mar 12 17:51:35 2025 +0800 scsi: hisi_sas: Fix I/O errors caused by hardware port ID changes [ Upstream commit daff37f00c7506ca322ccfce95d342022f06ec58 ] The hw port ID of phy may change when inserting disks in batches, causing the port ID in hisi_sas_port and itct to be inconsistent with the hardware, resulting in I/O errors. The solution is to set the device state to gone to intercept I/O sent to the device, and then execute linkreset to discard and find the disk to re-update its information. Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20250312095135.3048379-3-yangxingui@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 39ebdc2d51096c395da8f0fd140fab68682e5317 Author: Ojaswin Mujoo Date: Fri Mar 28 11:54:52 2025 +0530 ext4: make block validity check resistent to sb bh corruption [ Upstream commit ccad447a3d331a239477c281533bacb585b54a98 ] Block validity checks need to be skipped in case they are called for journal blocks since they are part of system's protected zone. Currently, this is done by checking inode->ino against sbi->s_es->s_journal_inum, which is a direct read from the ext4 sb buffer head. If someone modifies this underneath us then the s_journal_inum field might get corrupted. To prevent against this, change the check to directly compare the inode with journal->j_inode. **Slight change in behavior**: During journal init path, check_block_validity etc might be called for journal inode when sbi->s_journal is not set yet. In this case we now proceed with ext4_inode_block_valid() instead of returning early. Since systems zones have not been set yet, it is okay to proceed so we can perform basic checks on the blocks. Suggested-by: Baokun Li Reviewed-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Signed-off-by: Ojaswin Mujoo Link: https://patch.msgid.link/0c06bc9ebfcd6ccfed84a36e79147bf45ff5adc1.1743142920.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0c2aea3235a31b3b56630ec05319a6f85857a5af Author: Daniel Wagner Date: Tue Apr 8 17:29:10 2025 +0200 nvmet-fc: put ref when assoc->del_work is already scheduled [ Upstream commit 70289ae5cac4d3a39575405aaf63330486cea030 ] Do not leak the tgtport reference when the work is already scheduled. Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b7f235cb883e4ac7691b32c7e6c50f40c3a09aaf Author: Daniel Wagner Date: Tue Apr 8 17:29:09 2025 +0200 nvmet-fc: take tgtport reference only once [ Upstream commit b0b26ad0e1943de25ce82a7e5af3574f31b1cf99 ] The reference counting code can be simplified. Instead taking a tgtport refrerence at the beginning of nvmet_fc_alloc_hostport and put it back if not a new hostport object is allocated, only take it when a new hostport object is allocated. Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2184c4297175ca56858e8cfdb9e9690ebcf709d6 Author: Josh Poimboeuf Date: Tue Apr 8 14:47:34 2025 -0700 x86/bugs: Don't fill RSB on context switch with eIBRS [ Upstream commit 27ce8299bc1ec6df8306073785ff82b30b3cc5ee ] User->user Spectre v2 attacks (including RSB) across context switches are already mitigated by IBPB in cond_mitigation(), if enabled globally or if either the prev or the next task has opted in to protection. RSB filling without IBPB serves no purpose for protecting user space, as indirect branches are still vulnerable. User->kernel RSB attacks are mitigated by eIBRS. In which case the RSB filling on context switch isn't needed, so remove it. Suggested-by: Pawan Gupta Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Pawan Gupta Reviewed-by: Amit Shah Reviewed-by: Nikolay Borisov Link: https://lore.kernel.org/r/98cdefe42180358efebf78e3b80752850c7a3e1b.1744148254.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 3b2efa56954394cbe68c805285528be748621b22 Author: Josh Poimboeuf Date: Tue Apr 8 14:47:33 2025 -0700 x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline [ Upstream commit 18bae0dfec15b24ec14ca17dc18603372f5f254f ] eIBRS protects against guest->host RSB underflow/poisoning attacks. Adding retpoline to the mix doesn't change that. Retpoline has a balanced CALL/RET anyway. So the current full RSB filling on VMEXIT with eIBRS+retpoline is overkill. Disable it or do the VMEXIT_LITE mitigation if needed. Suggested-by: Pawan Gupta Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Pawan Gupta Reviewed-by: Amit Shah Reviewed-by: Nikolay Borisov Cc: Paolo Bonzini Cc: Vitaly Kuznetsov Cc: Sean Christopherson Cc: David Woodhouse Link: https://lore.kernel.org/r/84a1226e5c9e2698eae1b5ade861f1b8bf3677dc.1744148254.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 14b1cbf034a37c8cb26d1c107f8576d50e1b0216 Author: Josh Poimboeuf Date: Tue Apr 8 14:47:31 2025 -0700 x86/bugs: Use SBPB in write_ibpb() if applicable [ Upstream commit fc9fd3f98423367c79e0bd85a9515df26dc1b3cc ] write_ibpb() does IBPB, which (among other things) flushes branch type predictions on AMD. If the CPU has SRSO_NO, or if the SRSO mitigation has been disabled, branch type flushing isn't needed, in which case the lighter-weight SBPB can be used. The 'x86_pred_cmd' variable already keeps track of whether IBPB or SBPB should be used. Use that instead of hardcoding IBPB. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/17c5dcd14b29199b75199d67ff7758de9d9a4928.1744148254.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 6c94a16ba2da9a07d63429c1ca2befeb9babc0b9 Author: Qiuxu Zhuo Date: Tue Mar 11 16:09:40 2025 +0800 selftests/mincore: Allow read-ahead pages to reach the end of the file [ Upstream commit 197c1eaa7ba633a482ed7588eea6fd4aa57e08d4 ] When running the mincore_selftest on a system with an XFS file system, it failed the "check_file_mmap" test case due to the read-ahead pages reaching the end of the file. The failure log is as below: RUN global.check_file_mmap ... mincore_selftest.c:264:check_file_mmap:Expected i (1024) < vec_size (1024) mincore_selftest.c:265:check_file_mmap:Read-ahead pages reached the end of the file check_file_mmap: Test failed FAIL global.check_file_mmap This is because the read-ahead window size of the XFS file system on this machine is 4 MB, which is larger than the size from the #PF address to the end of the file. As a result, all the pages for this file are populated. blockdev --getra /dev/nvme0n1p5 8192 blockdev --getbsz /dev/nvme0n1p5 512 This issue can be fixed by extending the current FILE_SIZE 4MB to a larger number, but it will still fail if the read-ahead window size of the file system is larger enough. Additionally, in the real world, read-ahead pages reaching the end of the file can happen and is an expected behavior. Therefore, allowing read-ahead pages to reach the end of the file is a better choice for the "check_file_mmap" test case. Link: https://lore.kernel.org/r/20250311080940.21413-1-qiuxu.zhuo@intel.com Reported-by: Yi Lai Signed-off-by: Qiuxu Zhuo Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 4aebc6708c38da9bae90f6c7c2bec2357468c7cc Author: Josh Poimboeuf Date: Tue Apr 8 00:02:15 2025 -0700 objtool: Stop UNRET validation on UD2 [ Upstream commit 9f9cc012c2cbac4833746a0182e06a8eec940d19 ] In preparation for simplifying INSN_SYSCALL, make validate_unret() terminate control flow on UD2 just like validate_branch() already does. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/ce841269e7e28c8b7f32064464a9821034d724ff.1744095216.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 498027367f4af565fce8d6399a0c58bda0e78821 Author: Hannes Reinecke Date: Thu Apr 3 09:19:30 2025 +0200 nvme: re-read ANA log page after ns scan completes [ Upstream commit 62baf70c327444338c34703c71aa8cc8e4189bd6 ] When scanning for new namespaces we might have missed an ANA AEN. The NVMe base spec (NVMe Base Specification v2.1, Figure 151 'Asynchonous Event Information - Notice': Asymmetric Namespace Access Change) states: A controller shall not send this even if an Attached Namespace Attribute Changed asynchronous event [...] is sent for the same event. so we need to re-read the ANA log page after we rescanned the namespace list to update the ANA states of the new namespaces. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 510ba30dd37bb3c9355bc8d44a75eee56cba04f8 Author: Jean-Marc Eurin Date: Tue Apr 1 17:15:42 2025 -0700 ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls [ Upstream commit 7ab4f0e37a0f4207e742a8de69be03984db6ebf0 ] The end of table checks should be done with the structure size, but 2 of the 3 similar calls use the pointer size. Signed-off-by: Jean-Marc Eurin Link: https://patch.msgid.link/20250402001542.2600671-1-jmeurin@google.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d4444abc1924899d687fa6f393894a7b862f7b57 Author: Mario Limonciello Date: Tue Apr 1 08:38:51 2025 -0500 ACPI: EC: Set ec_no_wakeup for Lenovo Go S [ Upstream commit b988685388effd648150aab272533f833a2a70f0 ] When AC adapter is unplugged or plugged in EC wakes from HW sleep but APU doesn't enter back into HW sleep. The reason this happens is that, when the APU exits HW sleep, the power rails controlled by the EC will power up the TCON. The TCON has a GPIO that will be toggled at this time. The GPIO is not marked as a wakeup source, but the GPIO controller still has an unserviced interrupt. Unserviced interrupts will block entering HW sleep again. Clearing the GPIO doesn't help as the TCON continues to assert it until it's been initialized by i2c-hid. Fixing this would require TCON F/W changes and it's already broken in the wild on production hardware. To avoid triggering this issue add a quirk to avoid letting EC wake up system at all. The power button still works properly on this system. Reported-by: Antheas Kapenekakis Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3929 Link: https://github.com/bazzite-org/patchwork/commit/95b93b2852718ee1e808c72e6b1836da4a95fc63 Co-developed-by: Antheas Kapenekakis Signed-off-by: Antheas Kapenekakis Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20250401133858.1892077-1-superm1@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 2fbd0e19301f380be96f7aebc836e4ef359afc06 Author: Hannes Reinecke Date: Thu Apr 3 09:19:29 2025 +0200 nvme: requeue namespace scan on missed AENs [ Upstream commit 9546ad1a9bda7362492114f5866b95b0ac4a100e ] Scanning for namespaces can take some time, so if the target is reconfigured while the scan is running we may miss a Attached Namespace Attribute Changed AEN. Check if the NVME_AER_NOTICE_NS_CHANGED bit is set once the scan has finished, and requeue scanning to pick up any missed change. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e9f8bfb80e805d95fc624e9264e61df64ca9a7a3 Author: Jason Andryuk Date: Mon Mar 31 13:29:12 2025 -0400 xen: Change xen-acpi-processor dom0 dependency [ Upstream commit 0f2946bb172632e122d4033e0b03f85230a29510 ] xen-acpi-processor functions under a PVH dom0 with only a xen_initial_domain() runtime check. Change the Kconfig dependency from PV dom0 to generic dom0 to reflect that. Suggested-by: Jan Beulich Signed-off-by: Jason Andryuk Reviewed-by: Juergen Gross Tested-by: Jan Beulich Signed-off-by: Juergen Gross Message-ID: <20250331172913.51240-1-jason.andryuk@amd.com> Signed-off-by: Sasha Levin commit 9ce224eb5a9aaf68cb063bd19014b270b0ac89d3 Author: Ming Lei Date: Fri Apr 4 08:18:49 2025 +0800 selftests: ublk: fix test_stripe_04 [ Upstream commit 72070e57b0a518ec8e562a2b68fdfc796ef5c040 ] Commit 57ed58c13256 ("selftests: ublk: enable zero copy for stripe target") added test entry of test_stripe_04, but forgot to add the test script. So fix the test by adding the script file. Reported-by: Uday Shankar Signed-off-by: Ming Lei Reviewed-by: Uday Shankar Link: https://lore.kernel.org/r/20250404001849.1443064-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3f6c9d66e0f8eb9679b57913aa64b4d2266f6fbe Author: Xiaogang Chen Date: Fri Mar 21 11:41:26 2025 -0500 udmabuf: fix a buf size overflow issue during udmabuf creation [ Upstream commit 021ba7f1babd029e714d13a6bf2571b08af96d0f ] by casting size_limit_mb to u64 when calculate pglimit. Signed-off-by: Xiaogang Chen Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaogang.chen@amd.com Signed-off-by: Christian König Signed-off-by: Sasha Levin commit b16d315a18c114fb587f38a729e43b8db0021e2b Author: Thomas Weißschuh Date: Mon Feb 17 14:13:56 2025 +0100 KVM: s390: Don't use %pK through tracepoints [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh Reviewed-by: Michael Mueller Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa@linutronix.de Signed-off-by: Janosch Frank Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa@linutronix.de> Signed-off-by: Sasha Levin commit dcd21345eb96b36fbc1d021aeeae4badf2ca9f1d Author: Oleg Nesterov Date: Sun Mar 30 15:49:55 2025 +0200 sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP [ Upstream commit 975776841e689dd8ba36df9fa72ac3eca3c2957a ] kernel/sched/isolation.c obviously makes no sense without CONFIG_SMP, but the Kconfig entry we have right now: config CPU_ISOLATION bool "CPU isolation" depends on SMP || COMPILE_TEST allows the creation of pointless .config's which cause build failures. Reported-by: kernel test robot Signed-off-by: Oleg Nesterov Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250330134955.GA7910@redhat.com Closes: https://lore.kernel.org/oe-kbuild-all/202503260646.lrUqD3j5-lkp@intel.com/ Signed-off-by: Sasha Levin commit b22fac54c510e2cf83c6cb1c1dbdd6ff043c9d95 Author: Lukas Stockmann Date: Mon Jan 20 10:34:49 2025 +0100 rtc: pcf85063: do a SW reset if POR failed [ Upstream commit 2b7cbd98495f6ee4cd6422fe77828a19e9edf87f ] Power-on Reset has a documented issue in PCF85063, refer to its datasheet, section "Software reset": "There is a low probability that some devices will have corruption of the registers after the automatic power-on reset if the device is powered up with a residual VDD level. It is required that the VDD starts at zero volts at power up or upon power cycling to ensure that there is no corruption of the registers. If this is not possible, a reset must be initiated after power-up (i.e. when power is stable) with the software reset command" Trigger SW reset if there is an indication that POR has failed. Link: https://www.nxp.com/docs/en/data-sheet/PCF85063A.pdf Signed-off-by: Lukas Stockmann Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20250120093451.30778-1-alexander.sverdlin@siemens.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 468ff4a7c61fb811c596a7c44b6a5455e40fd12b Author: Dominique Martinet Date: Wed Mar 19 20:20:15 2025 +0900 9p/net: fix improper handling of bogus negative read/write replies [ Upstream commit d0259a856afca31d699b706ed5e2adf11086c73b ] In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3) Reported-by: Robert Morris Closes: https://lore.kernel.org/16271.1734448631@26-5-164.dynamic.csail.mit.edu Message-ID: <20250319-9p_unsigned_rw-v3-1-71327f1503d0@codewreck.org> Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 43b498a8452d613ae6339809ab4ac49abc299bd4 Author: Basavaraj Natikar Date: Wed Mar 12 20:02:16 2025 +0530 ntb_hw_amd: Add NTB PCI ID for new gen CPU [ Upstream commit bf8a7ce7e4c7267a6f5f2b2023cfc459b330b25e ] Add NTB support for new generation of processor. Signed-off-by: Basavaraj Natikar Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 763bf67ed3317411d32e94014e0f5fd9c0017c9e Author: Arnd Bergmann Date: Fri Feb 21 09:57:25 2025 +0100 ntb: reduce stack usage in idt_scan_mws [ Upstream commit aff12700b8dd7422bfe2277696e192af4df9de8f ] idt_scan_mws() puts a large fixed-size array on the stack and copies it into a smaller dynamically allocated array at the end. On 32-bit targets, the fixed size can easily exceed the warning limit for possible stack overflow: drivers/ntb/hw/idt/ntb_hw_idt.c:1041:27: error: stack frame size (1032) exceeds limit (1024) in 'idt_scan_mws' [-Werror,-Wframe-larger-than] Change it to instead just always use dynamic allocation for the array from the start. It's too big for the stack, but not actually all that much for a permanent allocation. Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202205111109.PiKTruEj-lkp@intel.com/ Signed-off-by: Arnd Bergmann Reviewed-by: Dave Jiang Reviewed-by: Damien Le Moal Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 545defa656568c74590317cd30068f85134a8216 Author: Al Viro Date: Mon May 13 17:50:34 2024 -0600 qibfs: fix _another_ leak [ Upstream commit bdb43af4fdb39f844ede401bdb1258f67a580a27 ] failure to allocate inode => leaked dentry... this one had been there since the initial merge; to be fair, if we are that far OOM, the odds of failing at that particular allocation are low... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit f93a840d4b61b70d42e48ecf50cdd394cde16fbd Author: Josh Poimboeuf Date: Mon Mar 24 14:56:12 2025 -0700 objtool, lkdtm: Obfuscate the do_nothing() pointer [ Upstream commit 05026ea01e95ffdeb0e5ac8fb7fb1b551e3a8726 ] If execute_location()'s memcpy of do_nothing() gets inlined and unrolled by the compiler, it copies one word at a time: mov 0x0(%rip),%rax R_X86_64_PC32 .text+0x1374 mov %rax,0x38(%rbx) mov 0x0(%rip),%rax R_X86_64_PC32 .text+0x136c mov %rax,0x30(%rbx) ... Those .text references point to the middle of the function, causing objtool to complain about their lack of ENDBR. Prevent that by resolving the function pointer at runtime rather than build time. This fixes the following warning: drivers/misc/lkdtm/lkdtm.o: warning: objtool: execute_location+0x23: relocation to !ENDBR: .text+0x1378 Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Linus Torvalds Link: https://lore.kernel.org/r/30b9abffbddeb43c4f6320b1270fa9b4d74c54ed.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503191453.uFfxQy5R-lkp@intel.com/ Signed-off-by: Sasha Levin commit 4e57e330fb7e6ec18231f6d596ed8c5d4367924a Author: Josh Poimboeuf Date: Mon Mar 24 14:56:09 2025 -0700 objtool, ASoC: codecs: wcd934x: Remove potential undefined behavior in wcd934x_slim_irq_handler() [ Upstream commit 060aed9c0093b341480770457093449771cf1496 ] If 'port_id' is negative, the shift counts in wcd934x_slim_irq_handler() also become negative, resulting in undefined behavior due to shift out of bounds. If I'm reading the code correctly, that appears to be not possible, but with KCOV enabled, Clang's range analysis isn't always able to determine that and generates undefined behavior. As a result the code generation isn't optimal, and undefined behavior should be avoided regardless. Improve code generation and remove the undefined behavior by converting the signed variables to unsigned. Fixes the following warning with UBSAN: sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Mark Brown Cc: Srinivas Kandagatla Cc: Liam Girdwood Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Linus Torvalds Link: https://lore.kernel.org/r/7e863839ec7301bf9c0f429a03873d44e484c31c.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503180044.oH9gyPeg-lkp@intel.com/ Signed-off-by: Sasha Levin commit 5f9385723a361e2a321168dae2e5f6a470137673 Author: Josh Poimboeuf Date: Mon Mar 24 14:55:57 2025 -0700 objtool: Silence more KCOV warnings [ Upstream commit 6b023c7842048c4bbeede802f3cf36b96c7a8b25 ] In the past there were issues with KCOV triggering unreachable instruction warnings, which is why unreachable warnings are now disabled with CONFIG_KCOV. Now some new KCOV warnings are showing up with GCC 14: vmlinux.o: warning: objtool: cpuset_write_resmask() falls through to next function cpuset_update_active_cpus.cold() drivers/usb/core/driver.o: error: objtool: usb_deregister() falls through to next function usb_match_device() sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section All are caused by GCC KCOV not finishing an optimization, leaving behind a never-taken conditional branch to a basic block which falls through to the next function (or end of section). At a high level this is similar to the unreachable warnings mentioned above, in that KCOV isn't fully removing dead code. Treat it the same way by adding these to the list of warnings to ignore with CONFIG_KCOV. Reported-by: Ingo Molnar Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/66a61a0b65d74e072d3dc02384e395edb2adc3c5.1742852846.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/Z9iTsI09AEBlxlHC@gmail.com Closes: https://lore.kernel.org/oe-kbuild-all/202503180044.oH9gyPeg-lkp@intel.com/ Signed-off-by: Sasha Levin commit bc49c5103eb74c7e0b0dc6bcc8a4b4214260ff3c Author: Mika Westerberg Date: Tue Mar 4 10:53:21 2025 +0200 thunderbolt: Scan retimers after device router has been enumerated [ Upstream commit 75749d2c1d8cef439f8b69fa1f4f36d0fc3193e6 ] Thomas reported connection issues on AMD system with Pluggable UD-4VPD dock. After some experiments it looks like the device has some sort of internal timeout that triggers reconnect. This is completely against the USB4 spec, as there is no requirement for the host to enumerate the device right away or even at all. In Linux case the delay is caused by scanning of retimers on the link so we can work this around by doing the scanning after the device router has been enumerated. Reported-by: Thomas Lynema Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219748 Reviewed-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 7e8f1dbf9bbc6c33e09634b8e360597d99adb607 Author: Théo Lebrun Date: Wed Feb 5 18:36:46 2025 +0100 usb: host: xhci-plat: mvebu: use ->quirks instead of ->init_quirk() func [ Upstream commit 64eb182d5f7a5ec30227bce4f6922ff663432f44 ] Compatible "marvell,armada3700-xhci" match data uses the struct xhci_plat_priv::init_quirk() function pointer to add XHCI_RESET_ON_RESUME as quirk on XHCI. Instead, use the struct xhci_plat_priv::quirks field. Signed-off-by: Théo Lebrun Link: https://lore.kernel.org/r/20250205-s2r-cdns-v7-1-13658a271c3c@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 36d68151712e525450f0fbb3045e7110f0d9b610 Author: Chenyuan Yang Date: Mon Mar 10 20:27:05 2025 -0500 usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() [ Upstream commit 8c75f3e6a433d92084ad4e78b029ae680865420f ] The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250311012705.1233829-1-chenyuan0y@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e7bcd1e2b26d7f8815947747564e8639850e24e Author: Michal Pecio Date: Tue Mar 11 17:45:51 2025 +0200 usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running [ Upstream commit 28a76fcc4c85dd39633fb96edb643c91820133e3 ] Nothing prevents a broken HC from claiming that an endpoint is Running and repeatedly rejecting Stop Endpoint with Context State Error. Avoid infinite retries and give back cancelled TDs. No such cases known so far, but HCs have bugs. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250311154551.4035726-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d9a60dd67b2bc510d687348056d68001a6356602 Author: Vinicius Costa Gomes Date: Wed Mar 5 15:00:06 2025 -0800 dmaengine: dmatest: Fix dmatest waiting less when interrupted [ Upstream commit e87ca16e99118ab4e130a41bdf12abbf6a87656c ] Change the "wait for operation finish" logic to take interrupts into account. When using dmatest with idxd DMA engine, it's possible that during longer tests, the interrupt notifying the finish of an operation happens during wait_event_freezable_timeout(), which causes dmatest to cleanup all the resources, some of which might still be in use. This fix ensures that the wait logic correctly handles interrupts, preventing premature cleanup of resources. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202502171134.8c403348-lkp@intel.com Signed-off-by: Vinicius Costa Gomes Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250305230007.590178-1-vinicius.gomes@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 54c7b864fbe4423a07b443a4ada0106052942116 Author: John Stultz Date: Thu Jan 16 11:40:59 2025 -0800 sound/virtio: Fix cancel_sync warnings on uninitialized work_structs [ Upstream commit 3c7df2e27346eb40a0e86230db1ccab195c97cfe ] Betty reported hitting the following warning: [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct. Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct. When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning. Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing. Feedback or thoughts would be appreciated! Cc: Anton Yakovlev Cc: "Michael S. Tsirkin" Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: virtualization@lists.linux.dev Cc: linux-sound@vger.kernel.org Cc: kernel-team@android.com Reported-by: Betty Zhou Suggested-by: Takashi Iwai Signed-off-by: John Stultz Message-Id: <20250116194114.3375616-1-jstultz@google.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit c2902e8abc081adaa61ed40b4f849e012958fbbc Author: Andy Shevchenko Date: Wed Feb 12 21:28:04 2025 +0200 usb: dwc3: gadget: Avoid using reserved endpoints on Intel Merrifield [ Upstream commit 461f24bff86808ee5fbfe74751a825f8a7ab24e0 ] Intel Merrifield SoC uses these endpoints for tracing and they cannot be re-allocated if being used because the side band flow control signals are hard wired to certain endpoints: • 1 High BW Bulk IN (IN#1) (RTIT) • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8) In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System Trace Module) unit and the EXI target driver will as well configure the TRB location for EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage these endpoints and interface to OTG3 controller through EBC interface, there is no need to enable any events (such as XferComplete etc) for these end points. Signed-off-by: Andy Shevchenko Tested-by: Ferry Toth Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250212193116.2487289-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a7a27cf25b2bf9a06848eb3e933f9f05763dea53 Author: Andy Shevchenko Date: Wed Feb 12 21:28:02 2025 +0200 usb: dwc3: gadget: Refactor loop to avoid NULL endpoints [ Upstream commit eafba0205426091354f050381c32ad1567c35844 ] Prepare the gadget driver to handle the reserved endpoints that will be not allocated at the initialisation time. While at it, add a warning where the NULL endpoint should never happen. Signed-off-by: Andy Shevchenko Tested-by: Ferry Toth Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250212193116.2487289-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 609c9ea78769d87508d60035eeae9f4e6ed277dc Author: Edward Adam Davis Date: Mon Oct 14 20:16:38 2024 +0800 fs/ntfs3: Fix WARNING in ntfs_extend_initialized_size [ Upstream commit ff355926445897cc9fdea3b00611e514232c213c ] Syzbot reported a WARNING in ntfs_extend_initialized_size. The data type of in->i_valid and to is u64 in ntfs_file_mmap(). If their values are greater than LLONG_MAX, overflow will occur because the data types of the parameters valid and new_valid corresponding to the function ntfs_extend_initialized_size() are loff_t. Before calling ntfs_extend_initialized_size() in the ntfs_file_mmap(), the "ni->i_valid < to" has been determined, so the same WARN_ON determination is not required in ntfs_extend_initialized_size(). Just execute the ntfs_extend_initialized_size() in ntfs_extend() to make a WARN_ON check. Reported-and-tested-by: syzbot+e37dd1dfc814b10caa55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e37dd1dfc814b10caa55 Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 27b12b58780483c91d775787e28b3f9fd844ea3e Author: Alexander Stein Date: Tue Jan 28 20:51:13 2025 +0100 usb: host: max3421-hcd: Add missing spi_device_id table [ Upstream commit 41d5e3806cf589f658f92c75195095df0b66f66a ] "maxim,max3421" DT compatible is missing its SPI device ID entry, not allowing module autoloading and leading to the following message: "SPI driver max3421-hcd has no spi_device_id for maxim,max3421" Fix this by adding the spi_device_id table. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250128195114.56321-1-alexander.stein@mailbox.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57089df327c7883cf3c9202d53cbe35478ecbfb7 Author: Haoxiang Li Date: Tue Feb 18 11:41:04 2025 +0800 s390/tty: Fix a potential memory leak bug [ Upstream commit ad9bb8f049717d64c5e62b2a44954be9f681c65b ] The check for get_zeroed_page() leads to a direct return and overlooked the memory leak caused by loop allocation. Add a free helper to free spaces allocated by get_zeroed_page(). Signed-off-by: Haoxiang Li Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250218034104.2436469-1-haoxiang_li2024@163.com Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 397254706eba9d8f99fd237feede7ab3169a7f9a Author: Haoxiang Li Date: Tue Feb 18 10:52:16 2025 +0800 s390/sclp: Add check for get_zeroed_page() [ Upstream commit 3db42c75a921854a99db0a2775814fef97415bac ] Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job. Signed-off-by: Haoxiang Li Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250218025216.2421548-1-haoxiang_li2024@163.com Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit d0db2eb9902961dac019c1043449ffce776fe997 Author: Yu-Chun Lin Date: Sun Feb 9 01:43:04 2025 +0800 parisc: PDT: Fix missing prototype warning [ Upstream commit b899981750dcb958ceffa4462d903963ee494aa2 ] As reported by the kernel test robot, the following error occurs: arch/parisc/kernel/pdt.c:65:6: warning: no previous prototype for 'arch_report_meminfo' [-Wmissing-prototypes] 65 | void arch_report_meminfo(struct seq_file *m) | ^~~~~~~~~~~~~~~~~~~ arch_report_meminfo() is declared in include/linux/proc_fs.h and only defined when CONFIG_PROC_FS is enabled. Wrap its definition in #ifdef CONFIG_PROC_FS to fix the -Wmissing-prototypes warning. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502082315.IPaHaTyM-lkp@intel.com/ Signed-off-by: Yu-Chun Lin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 2236d765a3658b57fd5ced80398fc963eaddac0d Author: Heiko Stuebner Date: Sat Feb 22 23:37:33 2025 +0100 clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec() [ Upstream commit b20150d499b3ee5c2d632fbc5ac94f98dd33accf ] of_clk_get_hw_from_clkspec() checks all available clock-providers by comparing their of nodes to the one from the clkspec. If no matching clock provider is found, the function returns -EPROBE_DEFER to cause a re-check at a later date. If a matching clock provider is found, an authoritative answer can be retrieved from it whether the clock exists or not. This does not take into account that the clock-provider may never appear, because it's node is disabled. This can happen when a clock is optional, provided by a separate block which never gets enabled. One example of this happening is the rk3588's VOP, which has optional additional display clocks coming from PLLs inside the hdmiphy blocks. These can be used for better rates, but the system will also work without them. The problem around that is described in the followups to[1]. As we already know the of node of the presumed clock provider, add a check via of_device_is_available() whether this is a "valid" device node. This prevents eternal defer loops. Link: https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/ [1] Reviewed-by: Sebastian Reichel Tested-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20250222223733.2990179-1-heiko@sntech.de [sboyd@kernel.org: Reword commit text a bit] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 255cbc9db7067a83713fd2f4b31034ddd266549a Author: Alexei Starovoitov Date: Mon Feb 24 14:16:37 2025 -0800 bpf: Fix deadlock between rcu_tasks_trace and event_mutex. [ Upstream commit 4580f4e0ebdf8dc8d506ae926b88510395a0c1d1 ] Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency. Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250224221637.4780-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit e27244cbe10658a66b8775be7f0acc4ad2f618d6 Author: Herbert Xu Date: Wed Feb 12 14:10:07 2025 +0800 crypto: null - Use spin lock instead of mutex [ Upstream commit dcc47a028c24e793ce6d6efebfef1a1e92f80297 ] As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm. Reported-by: syzbot+b3e02953598f447d4d2a@syzkaller.appspotmail.com Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit aba9e3096b98e5c7d99eb3e4e0a9a35f2f461475 Author: Gregory CLEMENT Date: Thu Jan 23 12:01:56 2025 +0100 MIPS: cm: Detect CM quirks from device tree [ Upstream commit e27fbe16af5cfc40639de4ced67d1a866a1953e9 ] Some information that should be retrieved at runtime for the Coherence Manager can be either absent or wrong. This patch allows checking if some of this information is available from the device tree and updates the internal variable accordingly. For now, only the compatible string associated with the broken HCI is being retrieved. Signed-off-by: Gregory CLEMENT Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ba9bf51801acbc7b36739eaa8093358bf1eaa36b Author: Chenyuan Yang Date: Mon Feb 10 17:25:52 2025 -0600 pinctrl: renesas: rza2: Fix potential NULL pointer dereference [ Upstream commit f752ee5b5b86b5f88a5687c9eb0ef9b39859b908 ] `chip.label` in rza2_gpio_register() could be NULL. Add the missing check. Signed-off-by: Chenyuan Yang Reviewed-by: Geert Uytterhoeven Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/20250210232552.1545887-1-chenyuan0y@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 64ebb33768351b5f3440bc2a6cefc1e26e573e9c Author: Oliver Neukum Date: Tue Apr 1 10:45:41 2025 +0200 USB: wdm: add annotation commit 73e9cc1ffd3650b12c4eb059dfdafd56e725ceda upstream. This is not understandable without a comment on endianness Fixes: afba937e540c9 ("USB: CDC WDM driver") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-5-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit e0917befd1a0fc7f19a1e24a1a1128bb1da6e554 Author: Oliver Neukum Date: Tue Apr 1 10:45:40 2025 +0200 USB: wdm: wdm_wwan_port_tx_complete mutex in atomic context commit 1fdc4dca350c0b8ada0b8ebf212504e1ad55e511 upstream. wdm_wwan_port_tx_complete is called from a completion handler with irqs disabled and possible in IRQ context usb_autopm_put_interface can take a mutex. Hence usb_autopm_put_interface_async must be used. Fixes: cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-4-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 217fe1fc7d112595a793e02b306710e702eac492 Author: Oliver Neukum Date: Tue Apr 1 10:45:39 2025 +0200 USB: wdm: close race between wdm_open and wdm_wwan_port_stop commit c1846ed4eb527bdfe6b3b7dd2c78e2af4bf98f4f upstream. Clearing WDM_WWAN_IN_USE must be the last action or we can open a chardev whose URBs are still poisoned Fixes: cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-3-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 15a7f14737b0c16eea349773618910ce4a4333ec Author: Oliver Neukum Date: Tue Apr 1 10:45:38 2025 +0200 USB: wdm: handle IO errors in wdm_wwan_port_start commit 9697f5efcf5fdea65b8390b5eb81bebe746ceedc upstream. In case submitting the URB fails we must undo what we've done so far. Fixes: cac6fb015f71 ("usb: class: cdc-wdm: WWAN framework integration") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250401084749.175246-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 6b607ae3f4f980b0d5afb64c87723e623e25a8c5 Author: Oliver Neukum Date: Tue Apr 8 15:57:46 2025 +0200 USB: VLI disk crashes if LPM is used commit e00b39a4f3552c730f1e24c8d62c4a8c6aad4e5d upstream. This device needs the NO_LPM quirk. Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250408135800.792515-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 219716ce07e3478e58cba9c5284fbad1f57d3891 Author: Miao Li Date: Mon Apr 14 14:29:35 2025 +0800 usb: quirks: Add delay init quirk for SanDisk 3.2Gen1 Flash Drive commit 37ffdbd695c02189dbf23d6e7d2385e0299587ca upstream. The SanDisk 3.2Gen1 Flash Drive, which VID:PID is in 0781:55a3, just like Silicon Motion Flash Drive: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com also needs the DELAY_INIT quirk, or it will randomly work incorrectly (e.g.: lsusb and can't list this device info) when connecting Huawei hisi platforms and doing thousand of reboot test circles. Cc: stable Signed-off-by: Miao Li Signed-off-by: Lei Huang Link: https://lore.kernel.org/r/20250414062935.159024-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman commit a408b8043ace5a8c59a1d97d7a55cf7ec7089638 Author: Miao Li Date: Tue Apr 1 10:30:27 2025 +0800 usb: quirks: add DELAY_INIT quirk for Silicon Motion Flash Drive commit 2932b6b547ec36ad2ed60fbf2117c0e46bb7d40a upstream. Silicon Motion Flash Drive connects to Huawei hisi platforms and performs a system reboot test for two thousand circles, it will randomly work incorrectly on boot, set DELAY_INIT quirk can workaround this issue. Signed-off-by: Miao Li Cc: stable Link: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman commit 07b491b601e507d931ad64f5394ac425e4e36a3c Author: Mike Looijmans Date: Tue Mar 18 07:44:52 2025 +0100 usb: dwc3: xilinx: Prevent spike in reset signal commit 38d6e60b6f3a99f8f13bee22eab616136c2c0675 upstream. The "reset" GPIO controls the RESET signal to an external, usually ULPI PHY, chip. The original code path acquires the signal in LOW state, and then immediately asserts it HIGH again, if the reset signal defaulted to asserted, there'd be a short "spike" before the reset. Here is what happens depending on the pre-existing state of the reset signal: Reset (previously asserted): ~~~|_|~~~~|_______ Reset (previously deasserted): _____|~~~~|_______ ^ ^ ^ A B C At point A, the low going transition is because the reset line is requested using GPIOD_OUT_LOW. If the line is successfully requested, the first thing we do is set it high _without_ any delay. This is point B. So, a glitch occurs between A and B. Requesting the line using GPIOD_OUT_HIGH eliminates the A and B transitions. Instead we get: Reset (previously asserted) : ~~~~~~~~~~|______ Reset (previously deasserted): ____|~~~~~|______ ^ ^ A C Where A and C are the points described above in the code. Point B has been eliminated. The issue was found during code inspection. Also remove the cryptic "toggle ulpi .." comment. Fixes: ca05b38252d7 ("usb: dwc3: xilinx: Add gpio-reset support") Cc: stable Signed-off-by: Mike Looijmans Reviewed-by: Radhey Shyam Pandey Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250318064518.9320-1-mike.looijmans@topic.nl Signed-off-by: Greg Kroah-Hartman commit a44547015287a19001384fe94dbff84c92ce4ee1 Author: Frode Isaksen Date: Thu Apr 3 09:28:03 2025 +0200 usb: dwc3: gadget: check that event count does not exceed event buffer length commit 63ccd26cd1f6600421795f6ca3e625076be06c9f upstream. The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250403072907.448524-1-fisaksen@baylibre.com Signed-off-by: Greg Kroah-Hartman commit 8b4b7ad42a093ee12acafcbf83262f8d2eac37ba Author: Huacai Chen Date: Fri Mar 28 12:00:59 2025 +0800 USB: OHCI: Add quirk for LS7A OHCI controller (rev 0x02) commit bcb60d438547355b8f9ad48645909139b64d3482 upstream. The OHCI controller (rev 0x02) under LS7A PCI host has a hardware flaw. MMIO register with offset 0x60/0x64 is treated as legacy PS2-compatible keyboard/mouse interface, which confuse the OHCI controller. Since OHCI only use a 4KB BAR resource indeed, the LS7A OHCI controller's 32KB BAR is wrapped around (the second 4KB BAR space is the same as the first 4KB internally). So we can add an 4KB offset (0x1000) to the OHCI registers (from the PCI BAR resource) as a quirk. Cc: stable Suggested-by: Bjorn Helgaas Reviewed-by: Alan Stern Tested-by: Mingcong Bai Signed-off-by: Huacai Chen Link: https://lore.kernel.org/r/20250328040059.3672979-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman commit df727eba55bcc1312e4edeefcb1be95d84064bcb Author: Fedor Pchelkin Date: Sun Mar 16 13:26:56 2025 +0300 usb: chipidea: ci_hdrc_imx: implement usb_phy_init() error handling commit 8c531e0a8c2d82509ad97c6d3a1e6217c7ed136d upstream. usb_phy_init() may return an error code if e.g. its implementation fails to prepare/enable some clocks. And properly rollback on probe error path by calling the counterpart usb_phy_shutdown(). Found by Linux Verification Center (linuxtesting.org). Fixes: be9cae2479f4 ("usb: chipidea: imx: Fix ULPI on imx53") Cc: stable Signed-off-by: Fedor Pchelkin Acked-by: Peter Chen Link: https://lore.kernel.org/r/20250316102658.490340-4-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit d2daafc3f0b4d14a21ea5de2e91a32ab3aa4cad2 Author: Fedor Pchelkin Date: Sun Mar 16 13:26:55 2025 +0300 usb: chipidea: ci_hdrc_imx: fix call balance of regulator routines commit 8cab0e9a3f3e8d700179e0d6141643d54a267fd5 upstream. Upon encountering errors during the HSIC pinctrl handling section the regulator should be disabled. Use devm_add_action_or_reset() to let the regulator-disabling routine be handled by device resource management stack. Found by Linux Verification Center (linuxtesting.org). Fixes: 4d6141288c33 ("usb: chipidea: imx: pinctrl for HSIC is optional") Cc: stable Signed-off-by: Fedor Pchelkin Acked-by: Peter Chen Link: https://lore.kernel.org/r/20250316102658.490340-3-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 0ee460498ced49196149197c9f6d29a10e5e0798 Author: Fedor Pchelkin Date: Sun Mar 16 13:26:54 2025 +0300 usb: chipidea: ci_hdrc_imx: fix usbmisc handling commit 4e28f79e3dffa52d327b46d1a78dac16efb5810b upstream. usbmisc is an optional device property so it is totally valid for the corresponding data->usbmisc_data to have a NULL value. Check that before dereferencing the pointer. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 74adad500346 ("usb: chipidea: ci_hdrc_imx: decrement device's refcount in .remove() and in the error path of .probe()") Cc: stable Signed-off-by: Fedor Pchelkin Acked-by: Peter Chen Link: https://lore.kernel.org/r/20250316102658.490340-2-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit c27db84ed44e50ff90d9e3a2a25fae2e0a0fa015 Author: Ralph Siemsen Date: Tue Mar 18 11:09:32 2025 -0400 usb: cdns3: Fix deadlock when using NCM gadget commit a1059896f2bfdcebcdc7153c3be2307ea319501f upstream. The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget"). Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link. The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler. Cc: stable Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by: Ralph Siemsen Acked-by: Peter Chen Reviewed-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/20250318-rfs-cdns3-deadlock-v2-1-bfd9cfcee732@linaro.org Signed-off-by: Greg Kroah-Hartman commit 0a8f200a1aaffe5e87a012757a651d1d96c6e538 Author: Craig Hesling Date: Tue Apr 8 16:27:03 2025 -0700 USB: serial: simple: add OWON HDS200 series oscilloscope support commit 4cc01410e1c1dd075df10f750775c81d1cb6672b upstream. Add serial support for OWON HDS200 series oscilloscopes and likely many other pieces of OWON test equipment. OWON HDS200 series devices host two USB endpoints, designed to facilitate bidirectional SCPI. SCPI is a predominately ASCII text protocol for test/measurement equipment. Having a serial/tty interface for these devices lowers the barrier to entry for anyone trying to write programs to communicate with them. The following shows the USB descriptor for the OWON HDS272S running firmware V5.7.1: Bus 001 Device 068: ID 5345:1234 Owon PDS6062T Oscilloscope Negotiated speed: Full Speed (12Mbps) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 [unknown] bDeviceSubClass 0 [unknown] bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x5345 Owon idProduct 0x1234 PDS6062T Oscilloscope bcdDevice 1.00 iManufacturer 1 oscilloscope iProduct 2 oscilloscope iSerial 3 oscilloscope bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0029 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 5 Physical Interface Device bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 09 21 11 01 00 01 22 5f 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 Device Status: 0x0000 (Bus Powered) OWON appears to be using the same USB Vendor and Product ID for many of their oscilloscopes. Looking at the discussion about the USB vendor/product ID, in the link bellow, suggests that this VID/PID is shared with VDS, SDS, PDS, and now the HDS series oscilloscopes. Available documentation for these devices seems to indicate that all use a similar SCPI protocol, some with RS232 options. It is likely that this same simple serial setup would work correctly for them all. Link: https://usb-ids.gowdy.us/read/UD/5345/1234 Signed-off-by: Craig Hesling Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a5d0eaa074007229a14be3ed75deff8ff959c297 Author: Adam Xue Date: Mon Apr 14 14:14:37 2025 -0700 USB: serial: option: add Sierra Wireless EM9291 commit 968e1cbb1f6293c3add9607f80b5ce3d29f57583 upstream. Add Sierra Wireless EM9291. Interface 0: MBIM control 1: MBIM data 3: AT port 4: Diagnostic port T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90e3 Rev=00.06 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9291 S: SerialNumber=xxxxxxxxxxxxxxxx C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Adam Xue Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit acb866379e82b0351e79623a04bb06cb6977dec7 Author: Michael Ehrenreich Date: Mon Mar 17 06:17:15 2025 +0100 USB: serial: ftdi_sio: add support for Abacus Electrics Optical Probe commit b399078f882b6e5d32da18b6c696cc84b12f90d5 upstream. Abacus Electrics makes optical probes for interacting with smart meters over an optical interface. At least one version uses an FT232B chip (as detected by ftdi_sio) with a custom USB PID, which needs to be added to the list to make the device work in a plug-and-play fashion. Signed-off-by: Michael Ehrenreich Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fd93c803f21a1a0bdbabc4b99befc450c1d2ba24 Author: Ryo Takakura Date: Sat Apr 12 09:18:47 2025 +0900 serial: sifive: lock port in startup()/shutdown() callbacks commit e1ca3ff28ab1e2c1e70713ef3fa7943c725742c3 upstream. startup()/shutdown() callbacks access SIFIVE_SERIAL_IE_OFFS. The register is also accessed from write() callback. If console were printing and startup()/shutdown() callback gets called, its access to the register could be overwritten. Add port->lock to startup()/shutdown() callbacks to make sure their access to SIFIVE_SERIAL_IE_OFFS is synchronized against write() callback. Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") Signed-off-by: Ryo Takakura Reviewed-by: Petr Mladek Cc: stable@vger.kernel.org Reviewed-by: John Ogness Rule: add Link: https://lore.kernel.org/stable/20250330003522.386632-1-ryotkkr98%40gmail.com Link: https://lore.kernel.org/r/20250412001847.183221-1-ryotkkr98@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1adf7a11659258bb4db9f83eea367dd9bd00c97b Author: Stephan Gerhold Date: Tue Apr 8 19:22:47 2025 +0200 serial: msm: Configure correct working mode before starting earlycon commit 7094832b5ac861b0bd7ed8866c93cb15ef619996 upstream. The MSM UART DM controller supports different working modes, e.g. DMA or the "single-character mode", where all reads/writes operate on a single character rather than 4 chars (32-bit) at once. When using earlycon, __msm_console_write() always writes 4 characters at a time, but we don't know which mode the bootloader was using and we don't set the mode either. This causes garbled output if the bootloader was using the single-character mode, because only every 4th character appears in the serial console, e.g. "[ 00oni pi 000xf0[ 00i s 5rm9(l)l s 1 1 SPMTA 7:C 5[ 00A ade k d[ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'" If the bootloader was using the DMA ("DM") mode, output would likely fail entirely. Later, when the full serial driver probes, the port is re-initialized and output works as expected. Fix this also for earlycon by clearing the DMEN register and reset+re-enable the transmitter to apply the change. This ensures the transmitter is in the expected state before writing any output. Cc: stable Fixes: 0efe72963409 ("tty: serial: msm: Add earlycon support") Signed-off-by: Stephan Gerhold Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250408-msm-serial-earlycon-v1-1-429080127530@linaro.org Signed-off-by: Greg Kroah-Hartman commit 4d43b7091efe6771bda6fbc065be8a61f8a080f3 Author: Rengarajan S Date: Thu Mar 13 22:38:56 2025 +0530 misc: microchip: pci1xxxx: Fix incorrect IRQ status handling during ack commit e9d7748a7468581859d2b85b378135f9688a0aff upstream. Under irq_ack, pci1xxxx_assign_bit reads the current interrupt status, modifies and writes the entire value back. Since, the IRQ status bit gets cleared on writing back, the better approach is to directly write the bitmask to the register in order to preserve the value. Fixes: 1f4d8ae231f4 ("misc: microchip: pci1xxxx: Add gpio irq handler and irq helper functions irq_ack, irq_mask, irq_unmask and irq_set_type of irq_chip.") Cc: stable Signed-off-by: Rengarajan S Link: https://lore.kernel.org/r/20250313170856.20868-3-rengarajan.s@microchip.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1263d5f581908602c618c6665e683c4436383a09 Author: Rengarajan S Date: Thu Mar 13 22:38:55 2025 +0530 misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration commit 18eb77c75ed01439f96ae5c0f33461eb5134b907 upstream. Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq. A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler. Fixes: 194f9f94a516 ("misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling") Cc: stable Signed-off-by: Rengarajan S Link: https://lore.kernel.org/r/20250313170856.20868-2-rengarajan.s@microchip.com Signed-off-by: Greg Kroah-Hartman commit 023816bd5fa46fab94d1e7917fe131b79ed1fb41 Author: Sean Christopherson Date: Fri Apr 4 12:38:17 2025 -0700 KVM: x86: Reset IRTE to host control if *new* route isn't postable commit 9bcac97dc42d2f4da8229d18feb0fe2b1ce523a2 upstream. Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed. Fixes: efc644048ecd ("KVM: x86: Update IRTE for posted-interrupts") Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 38cfa866b7acba62acab22db53d2cb314b15f3ed Author: Sean Christopherson Date: Fri Apr 4 12:38:18 2025 -0700 KVM: x86: Explicitly treat routing entry type changes as changes commit bcda70c56f3e718465cab2aad260cf34183ce1ce upstream. Explicitly treat type differences as GSI routing changes, as comparing MSI data between two entries could get a false negative, e.g. if userspace changed the type but left the type-specific data as-is. Fixes: 515a0c79e796 ("kvm: irqfd: avoid update unmodified entries of the routing") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 05a5c6b0e8d3312c7db44d3939e18c034923fc93 Author: Alexander Usyskin Date: Tue Apr 8 16:00:05 2025 +0300 mei: me: add panther lake H DID commit 86ce5c0a1dec02e21b4c864b2bc0cc5880a2c13c upstream. Add Panther Lake H device id. Cc: stable Co-developed-by: Tomas Winkler Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Link: https://lore.kernel.org/r/20250408130005.1358140-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman commit 90757407ca48c361eb942f9044fc6db5ffd1527b Author: Oliver Neukum Date: Thu Apr 3 19:59:45 2025 +0200 USB: storage: quirk for ADATA Portable HDD CH94 commit 9ab75eee1a056f896b87d139044dd103adc532b9 upstream. Version 1.60 specifically needs this quirk. Version 2.00 is known good. Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250403180004.343133-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit c5b8a549ef1fcc6066b037a3962c79d60465ba0b Author: Haoxiang Li Date: Mon Mar 10 09:46:57 2025 +0100 mcb: fix a double free bug in chameleon_parse_gdd() commit 7c7f1bfdb2249f854a736d9b79778c7e5a29a150 upstream. In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails. Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus") Cc: stable Signed-off-by: Haoxiang Li Signed-off-by: Johannes Thumshirn Link: https://lore.kernel.org/r/6201d09e2975ae5789879f79a6de4c38de9edd4a.1741596225.git.jth@kernel.org Signed-off-by: Greg Kroah-Hartman commit f46d889308d7c9f24e12d521cbe69d3d276260e3 Author: Sean Christopherson Date: Fri Apr 4 12:38:16 2025 -0700 KVM: SVM: Allocate IR data using atomic allocation commit 7537deda36521fa8fff9133b39c46e31893606f2 upstream. Allocate SVM's interrupt remapping metadata using GFP_ATOMIC as svm_ir_list_add() is called with IRQs are disabled and irqfs.lock held when kvm_irq_routing_update() reacts to GSI routing changes. Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5d4636859a8d43eab361fc6dc4b8cfa149644614 Author: Petr Tesarik Date: Thu Apr 24 20:15:41 2025 +0800 LoongArch: Remove a bogus reference to ZONE_DMA commit c37325cbd91abe3bfab280b3b09947155abe8e07 upstream. Remove dead code. LoongArch does not have a DMA memory zone (24bit DMA). The architecture does not even define MAX_DMA_PFN. Cc: stable@vger.kernel.org Reviewed-by: Mike Rapoport (Microsoft) Signed-off-by: Petr Tesarik Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 34256805720993e37adf6127371a1265aea8376a Author: Ming Wang Date: Thu Apr 24 20:15:47 2025 +0800 LoongArch: Return NULL from huge_pte_offset() for invalid PMD commit bd51834d1cf65a2c801295d230c220aeebf87a73 upstream. LoongArch's huge_pte_offset() currently returns a pointer to a PMD slot even if the underlying entry points to invalid_pte_table (indicating no mapping). Callers like smaps_hugetlb_range() fetch this invalid entry value (the address of invalid_pte_table) via this pointer. The generic is_swap_pte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!pte_present() && !pte_none()" conditions. This misinterpretation, combined with a coincidental match by is_migration_entry() on the address bits, leads to kernel crashes in pfn_swap_entry_to_page(). Fix this at the architecture level by modifying huge_pte_offset() to check the PMD entry's content using pmd_none() before returning. If the entry is invalid (i.e., it points to invalid_pte_table), return NULL instead of the pointer to the slot. Cc: stable@vger.kernel.org Acked-by: Peter Xu Co-developed-by: Hongchen Zhang Signed-off-by: Hongchen Zhang Signed-off-by: Ming Wang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 128d261c7203edc1b5c6ff63fe8cefdf83ee3ef5 Author: Roman Li Date: Wed Mar 26 10:33:51 2025 -0400 drm/amd/display: Force full update in gpu reset commit 67fe574651c73fe5cc176e35f28f2ec1ba498d14 upstream. [Why] While system undergoing gpu reset always do full update to sync the dc state before and after reset. [How] Return true in should_reset_plane() if gpu reset detected Reviewed-by: Aurabindo Pillai Reviewed-by: Mario Limonciello Signed-off-by: Roman Li Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher (cherry picked from commit 2ba8619b9a378ad218ad6c2e2ccaee8f531e08de) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a4be735fe0f8537731ef0840ebfad0b70d44064b Author: Roman Li Date: Tue Apr 1 17:05:10 2025 -0400 drm/amd/display: Fix gpu reset in multidisplay config commit 7eb287beeb60be1e4437be2b4e4e9f0da89aab97 upstream. [Why] The indexing of stream_status in dm_gpureset_commit_state() is incorrect. That leads to asserts in multi-display configuration after gpu reset. [How] Adjust the indexing logic to align stream_status with surface_updates. Fixes: cdaae8371aa9 ("drm/amd/display: Handle GPU reset for DC block") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3808 Reviewed-by: Aurabindo Pillai Reviewed-by: Mario Limonciello Signed-off-by: Roman Li Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher (cherry picked from commit d91bc901398741d317d9b55c59ca949d4bc7394b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 24023ed8ffb361e269542ef69aa5747419310af0 Author: Oleksij Rempel Date: Wed Apr 16 18:01:25 2025 +0200 net: selftests: initialize TCP header and skb payload with zero commit 9e8d1013b0c38910cbc9e60de74dbe883878469d upstream. Zero-initialize TCP header via memset() to avoid garbage values that may affect checksum or behavior during test transmission. Also zero-fill allocated payload and padding regions using memset() after skb_put(), ensuring deterministic content for all outgoing test packets. Fixes: 3e1e58d64c3d ("net: add generic selftest support") Signed-off-by: Oleksij Rempel Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250416160125.2914724-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 5b83d30c63f9964acb1bc63eb8e670b9e0d2c240 Author: Alexey Nepomnyashih Date: Thu Apr 17 12:21:17 2025 +0000 xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() commit cc3628dcd851ddd8d418bf0c897024b4621ddc92 upstream. The function xdp_convert_buff_to_frame() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented. Cc: stable@vger.kernel.org # v5.9+ Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfront") Signed-off-by: Alexey Nepomnyashih Link: https://patch.msgid.link/20250417122118.1009824-1-sdl@nppct.ru Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit baa332e22f4f58618e934888a7c1fd02f35e80bd Author: Halil Pasic Date: Sat Mar 22 01:29:54 2025 +0100 virtio_console: fix missing byte order handling for cols and rows commit fbd3039a64b01b769040677c4fc68badeca8e3b2 upstream. As per virtio spec the fields cols and rows are specified as little endian. Although there is no legacy interface requirement that would state that cols and rows need to be handled as native endian when legacy interface is used, unlike for the fields of the adjacent struct virtio_console_control, I decided to err on the side of caution based on some non-conclusive virtio spec repo archaeology and opt for using virtio16_to_cpu() much like for virtio_console_control.event. Strictly by the letter of the spec virtio_le_to_cpu() would have been sufficient. But when the legacy interface is not used, it boils down to the same. And when using the legacy interface, the device formatting these as little endian when the guest is big endian would surprise me more than it using guest native byte order (which would make it compatible with the current implementation). Nevertheless somebody trying to implement the spec following it to the letter could end up forcing little endian byte order when the legacy interface is in use. So IMHO this ultimately needs a judgement call by the maintainers. Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along with resize control message") Signed-off-by: Halil Pasic Cc: stable@vger.kernel.org # v2.6.35+ Message-Id: <20250322002954.3129282-1-pasic@linux.ibm.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 4e8ce3978d704cb28678355d294e10a008b6230a Author: Ping-Ke Shih Date: Thu Aug 22 09:42:55 2024 +0800 wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb commit 3e5e4a801aaf4283390cc34959c6c48f910ca5ea upstream. When removing kernel modules by: rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core Driver uses skb_queue_purge() to purge TX skb, but not report tx status causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue() to correct this. Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing between TX work and purge TX queue, flush and destroy TX work in advance. wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local choice (Reason: 3=DEAUTH_LEAVING) ------------[ cut here ]------------ Have pending ack frames! WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691 ieee80211_free_ack_frame+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Tainted: G C 6.10.1-200.fc40.aarch64 #1 Hardware name: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0 x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Call trace: ieee80211_free_ack_frame+0x5c/0x90 [mac80211] idr_for_each+0x74/0x110 ieee80211_free_hw+0x44/0xe8 [mac80211] rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio] sdio_bus_remove+0x44/0x180 device_remove+0x54/0x90 device_release_driver_internal+0x1d4/0x238 driver_detach+0x54/0xc0 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x78 sdio_unregister_driver+0x2c/0x40 rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs] __do_sys_delete_module.isra.0+0x190/0x338 __arm64_sys_delete_module+0x1c/0x30 invoke_syscall+0x74/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 ---[ end trace 0000000000000000 ]--- Reported-by: Peter Robinson Closes: https://lore.kernel.org/linux-wireless/CALeDE9OAa56KMzgknaCD3quOgYuEHFx9_hcT=OFgmMAb+8MPyA@mail.gmail.com/ Tested-by: Ping-Ke Shih # 8723DU Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240822014255.10211-2-pkshih@realtek.com Signed-off-by: Ladislav Michl Signed-off-by: Greg Kroah-Hartman commit ff5a5dae30287b5b07d4bcf65cbe6af80570d29c Author: Ping-Ke Shih Date: Thu Aug 22 09:42:54 2024 +0800 wifi: mac80211: export ieee80211_purge_tx_queue() for drivers commit 53bc1b73b67836ac9867f93dee7a443986b4a94f upstream. Drivers need to purge TX SKB when stopping. Using skb_queue_purge() can't report TX status to mac80211, causing ieee80211_free_ack_frame() warns "Have pending ack frames!". Export ieee80211_purge_tx_queue() for drivers to not have to reimplement it. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240822014255.10211-1-pkshih@realtek.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4e773aea057efd568ae847dc8dd0df5b94c9cc6c Author: Tiezhu Yang Date: Thu Apr 24 20:15:41 2025 +0800 LoongArch: Make regs_irqs_disabled() more clear [ Upstream commit bb0511d59db9b3e40c8d51f0d151ccd0fd44071d ] In the current code, the definition of regs_irqs_disabled() is actually "!(regs->csr_prmd & CSR_CRMD_IE)" because arch_irqs_disabled_flags() is defined as "!(flags & CSR_CRMD_IE)", it looks a little strange. Define regs_irqs_disabled() as !(regs->csr_prmd & CSR_PRMD_PIE) directly to make it more clear, no functional change. While at it, the return value of regs_irqs_disabled() is true or false, so change its type to reflect that and also make it always inline. Fixes: 803b0fc5c3f2 ("LoongArch: Add process management") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit da3170fea441cc8fca7d9aec2f49ab73973e3c67 Author: Yuli Wang Date: Thu Apr 24 20:15:22 2025 +0800 LoongArch: Select ARCH_USE_MEMTEST [ Upstream commit fb8e9f59d6f292c3d9fea6c155c22ea5fc3053ab ] As of commit dce44566192e ("mm/memtest: add ARCH_USE_MEMTEST"), architectures must select ARCH_USE_MEMTESET to enable CONFIG_MEMTEST. Commit 628c3bb40e9a ("LoongArch: Add boot and setup routines") added support for early_memtest but did not select ARCH_USE_MEMTESET. Fixes: 628c3bb40e9a ("LoongArch: Add boot and setup routines") Tested-by: Erpeng Xu Tested-by: Yuli Wang Signed-off-by: Yuli Wang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit ecb3f8f8906704ecbef2a0effa2771d945d99f29 Author: Luo Gengkun Date: Wed Apr 23 06:47:24 2025 +0000 perf/x86: Fix non-sampling (counting) events on certain x86 platforms [ Upstream commit 1a97fea9db9e9b9c4839d4232dde9f505ff5b4cc ] Perf doesn't work at perf stat for hardware events on certain x86 platforms: $perf stat -- sleep 1 Performance counter stats for 'sleep 1': 16.44 msec task-clock # 0.016 CPUs utilized 2 context-switches # 121.691 /sec 0 cpu-migrations # 0.000 /sec 54 page-faults # 3.286 K/sec cycles instructions branches branch-misses The reason is that the check in x86_pmu_hw_config() for sampling events is unexpectedly applied to counting events as well. It should only impact x86 platforms with limit_period used for non-PEBS events. For Intel platforms, it should only impact some older platforms, e.g., HSW, BDW and NHM. Fixes: 88ec7eedbbd2 ("perf/x86: Fix low freqency setting issue") Signed-off-by: Luo Gengkun Signed-off-by: Ingo Molnar Reviewed-by: Kan Liang Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Link: https://lore.kernel.org/r/20250423064724.3716211-1-luogengkun@huaweicloud.com Signed-off-by: Sasha Levin commit 9e75c934728bbcf7582fdd783bd04206eadff940 Author: Sean Christopherson Date: Fri Apr 4 12:38:20 2025 -0700 iommu/amd: Return an error if vCPU affinity is set for non-vCPU IRTE [ Upstream commit 07172206a26dcf3f0bf7c3ecaadd4242b008ea54 ] Return -EINVAL instead of success if amd_ir_set_vcpu_affinity() is invoked without use_vapic; lying to KVM about whether or not the IRTE was configured to post IRQs is all kinds of bad. Fixes: d98de49a53e4 ("iommu/amd: Enable vAPIC interrupt remapping mode by default") Signed-off-by: Sean Christopherson Message-ID: <20250404193923.1413163-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 11bccb054c1462fb069219f8e98e97a5a730758e Author: Cong Wang Date: Thu Apr 17 11:47:31 2025 -0700 net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too [ Upstream commit 6ccbda44e2cc3d26fd22af54c650d6d5d801addf ] Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer. Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2") Reported-by: Gerrard Tai Signed-off-by: Cong Wang Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20250417184732.943057-3-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20d584a33e480ae80d105f43e0e7b56784da41b9 Author: Cong Wang Date: Thu Apr 17 11:47:30 2025 -0700 net_sched: hfsc: Fix a UAF vulnerability in class handling [ Upstream commit 3df275ef0a6ae181e8428a6589ef5d5231e58b5c ] This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel. The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied. Fixes: 21f4d5cc25ec ("net_sched/hfsc: fix curve activation in hfsc_change_class()") Reported-by: Gerrard Tai Reviewed-by: Konstantin Khlebnikov Signed-off-by: Cong Wang Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20250417184732.943057-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e79e8e05aa46f90d21023f0ffe6f136ed6a20932 Author: Tung Nguyen Date: Thu Apr 17 14:47:15 2025 +0700 tipc: fix NULL pointer dereference in tipc_mon_reinit_self() [ Upstream commit d63527e109e811ef11abb1c2985048fdb528b4cb ] syzbot reported: tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... | } | ... | } | ... | } | 'mon->self' is set to NULL in disabling_bearer thread and dereferenced later in enabling_bearer thread. This commit fixes this issue by validating 'mon->self' before assigning node address to it. Reported-by: syzbot+ed60da8d686dc709164c@syzkaller.appspotmail.com Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated") Signed-off-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250417074826.578115-1-tung.quang.nguyen@est.tech Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f41f097f68a33d392579885426d0734a81219501 Author: Qingfang Deng Date: Thu Apr 17 11:25:56 2025 +0800 net: phy: leds: fix memory leak [ Upstream commit b7f0ee992adf601aa00c252418266177eb7ac2bc ] A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code. The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound. This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer. Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path. Fixes: 3928ee6485a3 ("net: phy: leds: Add support for "link" trigger") Fixes: 2e0bc452f472 ("net: phy: leds: add support for led triggers on phy link state change") Signed-off-by: Hao Guan Signed-off-by: Qingfang Deng Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250417032557.2929427-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ceceff6d31d99fb8ce8ce4c8aae6b475aef94d55 Author: Justin Iurman Date: Wed Apr 16 18:07:16 2025 +0200 net: lwtunnel: disable BHs when required [ Upstream commit c03a49f3093a4903c8a93c8b5c9a297b5343b169 ] In lwtunnel_{output|xmit}(), dev_xmit_recursion() may be called in preemptible scope for PREEMPT kernels. This patch disables BHs before calling dev_xmit_recursion(). BHs are re-enabled only at the end, since we must ensure the same CPU is used for both dev_xmit_recursion_inc() and dev_xmit_recursion_dec() (and any other recursion levels in some cases) in order to maintain valid per-cpu counters. Reported-by: Alexei Starovoitov Closes: https://lore.kernel.org/netdev/CAADnVQJFWn3dBFJtY+ci6oN1pDFL=TzCmNbRgey7MdYxt_AP2g@mail.gmail.com/ Reported-by: Eduard Zingerman Closes: https://lore.kernel.org/netdev/m2h62qwf34.fsf@gmail.com/ Fixes: 986ffb3a57c5 ("net: lwtunnel: fix recursion loops") Signed-off-by: Justin Iurman Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250416160716.8823-1-justin.iurman@uliege.be Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 790bad9dc2c1737f7185d628db3f55b325a52ffd Author: Anastasia Kovaleva Date: Mon Mar 24 11:49:33 2025 +0300 scsi: core: Clear flags for scsi_cmnd that did not complete [ Upstream commit 54bebe46871d4e56e05fcf55c1a37e7efa24e0a8 ] Commands that have not been completed with scsi_done() do not clear the SCMD_INITIALIZED flag and therefore will not be properly reinitialized. Thus, the next time the scsi_cmnd structure is used, the command may fail in scsi_cmd_runtime_exceeded() due to the old jiffies_at_alloc value: kernel: sd 16:0:1:84: [sdts] tag#405 timing out command, waited 720s kernel: sd 16:0:1:84: [sdts] tag#405 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=66636s Clear flags for commands that have not been completed by SCSI. Fixes: 4abafdc4360d ("block: remove the initialize_rq_fn blk_mq_ops method") Signed-off-by: Anastasia Kovaleva Link: https://lore.kernel.org/r/20250324084933.15932-2-a.kovaleva@yadro.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fd18210acb4f2fbe510b0f29e888999e5f989cf1 Author: Qu Wenruo Date: Sat Mar 29 17:46:35 2025 +1030 btrfs: avoid page_lockend underflow in btrfs_punch_hole_lock_range() [ Upstream commit bc2dbc4983afedd198490cca043798f57c93e9bf ] [BUG] When running btrfs/004 with 4K fs block size and 64K page size, sometimes fsstress workload can take 100% CPU for a while, but not long enough to trigger a 120s hang warning. [CAUSE] When such 100% CPU usage happens, btrfs_punch_hole_lock_range() is always in the call trace. One example when this problem happens, the function btrfs_punch_hole_lock_range() got the following parameters: lock_start = 4096, lockend = 20469 Then we calculate @page_lockstart by rounding up lock_start to page boundary, which is 64K (page size is 64K). For @page_lockend, we round down the value towards page boundary, which result 0. Then since we need to pass an inclusive end to filemap_range_has_page(), we subtract 1 from the rounded down value, resulting in (u64)-1. In the above case, the range is inside the same page, and we do not even need to call filemap_range_has_page(), not to mention to call it with (u64)-1 at the end. This behavior will cause btrfs_punch_hole_lock_range() to busy loop waiting for irrelevant range to have its pages dropped. [FIX] Calculate @page_lockend by just rounding down @lockend, without decreasing the value by one. So @page_lockend will no longer overflow. Then exit early if @page_lockend is no larger than @page_lockstart. As it means either the range is inside the same page, or the two pages are adjacent already. Finally only decrease @page_lockend when calling filemap_range_has_page(). Fixes: 0528476b6ac7 ("btrfs: fix the filemap_range_has_page() call in btrfs_punch_hole_lock_range()") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a252684ea1c9da830a1ee2c816d4e3b4d6cd5bfd Author: Marc Zyngier Date: Sun Apr 13 11:11:42 2025 +0100 cpufreq: cppc: Fix invalid return value in .get() callback [ Upstream commit 2b8e6b58889c672e1ae3601d9b2b070be4dc2fbc ] Returning a negative error code in a function with an unsigned return type is a pretty bad idea. It is probably worse when the justification for the change is "our static analisys tool found it". Fixes: cf7de25878a1 ("cppc_cpufreq: Fix possible null pointer dereference") Signed-off-by: Marc Zyngier Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Reviewed-by: Lifeng Zheng Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit da8ee91e532486055ecf88478d38c2f3dc234182 Author: Henry Martin Date: Tue Apr 8 23:03:54 2025 +0800 cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() [ Upstream commit 73b24dc731731edf762f9454552cb3a5b7224949 ] cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency") Signed-off-by: Henry Martin Acked-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit f9c5423855e3687262d881aeee5cfb3bc8577bff Author: Henry Martin Date: Tue Apr 8 23:03:53 2025 +0800 cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() [ Upstream commit 484d3f15cc6cbaa52541d6259778e715b2c83c54 ] cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Add NULL check after cpufreq_cpu_get_raw() to prevent this issue. Fixes: 99d6bdf33877 ("cpufreq: add support for CPU DVFS based on SCMI message protocol") Signed-off-by: Henry Martin Acked-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 4bf6d7defb1f4296a34884022a19c8ec35293459 Author: Arnd Bergmann Date: Wed Apr 9 17:15:42 2025 +0200 dma/contiguous: avoid warning about unused size_bytes [ Upstream commit d7b98ae5221007d3f202746903d4c21c7caf7ea9 ] When building with W=1, this variable is unused for configs with CONFIG_CMA_SIZE_SEL_PERCENTAGE=y: kernel/dma/contiguous.c:67:26: error: 'size_bytes' defined but not used [-Werror=unused-const-variable=] Change this to a macro to avoid the warning. Fixes: c64be2bb1c6e ("drivers: add Contiguous Memory Allocator") Signed-off-by: Arnd Bergmann Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20250409151557.3890443-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 19cc82616b44eedeacbd149a15f44ef28656d923 Author: Mark Brown Date: Fri Apr 4 17:42:32 2025 +0100 selftests/mm: generate a temporary mountpoint for cgroup filesystem [ Upstream commit 9c02223e2d9df5cb37c51aedb78f3960294e09b5 ] Currently if the filesystem for the cgroups version it wants to use is not mounted charge_reserved_hugetlb.sh and hugetlb_reparenting_test.sh tests will attempt to mount it on the hard coded path /dev/cgroup/memory, deleting that directory when the test finishes. This will fail if there is not a preexisting directory at that path, and since the directory is deleted subsequent runs of the test will fail. Instead of relying on this hard coded directory name use mktemp to generate a temporary directory to use as a mountpoint, fixing both the assumption and the disruption caused by deleting a preexisting directory. This means that if the relevant cgroup filesystem is not already mounted then we rely on having coreutils (which provides mktemp) installed. I suspect that many current users are relying on having things automounted by default, and given that the script relies on bash it's probably not an unreasonable requirement. Link: https://lkml.kernel.org/r/20250404-kselftest-mm-cgroup2-detection-v1-1-3dba6d32ba8c@kernel.org Fixes: 209376ed2a84 ("selftests/vm: make charge_reserved_hugetlb.sh work with existing cgroup setting") Signed-off-by: Mark Brown Cc: Aishwarya TCV Cc: Mark Brown Cc: Mina Almasry Cc: Shuah Khan Cc: Waiman Long Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d78888853eb53f47ae16cf3aa5d0444d0331b9f8 Author: Evgeny Pimenov Date: Tue Apr 1 23:40:58 2025 +0300 ASoC: qcom: Fix sc7280 lpass potential buffer overflow [ Upstream commit a31a4934b31faea76e735bab17e63d02fcd8e029 ] Case values introduced in commit 5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()). Redefine LPASS_MAX_PORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 77d0ffef793d ("ASoC: qcom: Add macro for lpass DAI id's max limit") Cc: stable@vger.kernel.org # v6.0+ Suggested-by: Mikhail Kobuk Suggested-by: Alexey Khoroshilov Signed-off-by: Evgeny Pimenov Link: https://patch.msgid.link/20250401204058.32261-1-pimenoveu12@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 20ecb510d415416a2ba4174cbb2ff3f2dc0443a0 Author: Srinivas Kandagatla Date: Tue May 9 12:22:01 2023 +0100 ASoC: qcom: q6dsp: add support to more display ports [ Upstream commit 90848a2557fec0a6f1a35e58031a1f6f5e44e7d6 ] Existing code base only supports one display port, this patch adds support upto 8 display ports. This support is required to allow platforms like X13s which have 3 display ports, and some of the Qualcomm SoCs there are upto 7 Display ports. Signed-off-by: Srinivas Kandagatla commit 11f56f5a252be09ab766663abc118bdcf1ae75eb Author: Stefan Eichenberger Date: Wed Mar 5 15:43:16 2025 +0100 phy: freescale: imx8m-pcie: assert phy reset and perst in power off [ Upstream commit aecb63e88c5e5fb9afb782a1577264c76f179af9 ] Ensure the PHY reset and perst is asserted during power-off to guarantee it is in a reset state upon repeated power-on calls. This resolves an issue where the PHY may not properly initialize during subsequent power-on cycles. Power-on will deassert the reset at the appropriate time after tuning the PHY parameters. During suspend/resume cycles, we observed that the PHY PLL failed to lock during resume when the CPU temperature increased from 65C to 75C. The observed errors were: phy phy-32f00000.pcie-phy.3: phy poweron failed --> -110 imx6q-pcie 33800000.pcie: waiting for PHY ready timeout! imx6q-pcie 33800000.pcie: PM: dpm_run_callback(): genpd_resume_noirq+0x0/0x80 returns -110 imx6q-pcie 33800000.pcie: PM: failed to resume noirq: error -110 This resulted in a complete CPU freeze, which is resolved by ensuring the PHY is in reset during power-on, thus preventing PHY PLL failures. Cc: stable@vger.kernel.org Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Signed-off-by: Stefan Eichenberger Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250305144355.20364-3-eichest@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit cf0fbe3e9b2d0c4f8f3ff9b3f2b59d48ad21dacb Author: Richard Zhu Date: Thu Oct 13 09:47:02 2022 +0800 phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support [ Upstream commit dce9edff16ee8df20e791e82e0704c4667cc3908 ] Add i.MX8MP PCIe PHY support. Signed-off-by: Richard Zhu Signed-off-by: Lucas Stach Tested-by: Marek Vasut Tested-by: Richard Leitner Tested-by: Alexander Stein Reviewed-by: Lucas Stach Reviewed-by: Ahmad Fatoum Link: https://lore.kernel.org/r/1665625622-20551-5-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Vinod Koul Stable-dep-of: aecb63e88c5e ("phy: freescale: imx8m-pcie: assert phy reset and perst in power off") Signed-off-by: Sasha Levin commit b783478e0c53ffb4f04f25fb4e21ef7f482b05df Author: Ma Ke Date: Tue Feb 25 10:14:40 2025 +0800 PCI: Fix reference leak in pci_register_host_bridge() [ Upstream commit 804443c1f27883926de94c849d91f5b7d7d696e9 ] If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. Link: https://lore.kernel.org/r/20250225021440.3130264-1-make24@iscas.ac.cn Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Signed-off-by: Ma Ke [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ead4d69b3ef047b0f670511d81e9ced7ac876b44 Author: Pali Rohár Date: Thu Jul 14 20:41:30 2022 +0200 PCI: Assign PCI domain IDs by ida_alloc() [ Upstream commit c14f7ccc9f5dcf9d06ddeec706f85405b2c80600 ] Replace assignment of PCI domain IDs from atomic_inc_return() to ida_alloc(). Use two IDAs, one for static domain allocations (those which are defined in device tree) and second for dynamic allocations (all other). During removal of root bus / host bridge, also release the domain ID. The released ID can be reused again, for example when dynamically loading and unloading native PCI host bridge drivers. This change also allows to mix static device tree assignment and dynamic by kernel as all static allocations are reserved in dynamic pool. [bhelgaas: set "err" if "bus->domain_nr < 0"] Link: https://lore.kernel.org/r/20220714184130.5436-1-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Bjorn Helgaas Stable-dep-of: 804443c1f278 ("PCI: Fix reference leak in pci_register_host_bridge()") Signed-off-by: Sasha Levin commit 9c32eaf8e4c808fe9f91bc833a9bb025196c6c80 Author: Zijun Hu Date: Mon Feb 24 17:01:55 2025 -0600 of: resolver: Fix device node refcount leakage in of_resolve_phandles() [ Upstream commit a46a0805635d07de50c2ac71588345323c13b2f9 ] In of_resolve_phandles(), refcount of device node @local_fixups will be increased if the for_each_child_of_node() exits early, but nowhere to decrease the refcount, so cause refcount leakage for the node. Fix by using __free() on @local_fixups. Fixes: da56d04c806a ("of/resolver: Switch to new local fixups format.") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250209-of_irq_fix-v2-9-93e3a2659aa7@quicinc.com [robh: Use __free() instead] Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit fc7e57c56d7d26a28b0dae84e73454fda0745ceb Author: Rob Herring (Arm) Date: Sun Feb 9 20:59:02 2025 +0800 of: resolver: Simplify of_resolve_phandles() using __free() [ Upstream commit 5275e8b5293f65cc82a5ee5eab02dd573b911d6e ] Use the __free() cleanup to simplify of_resolve_phandles() and remove all the goto's. Signed-off-by: Rob Herring (Arm) Stable-dep-of: a46a0805635d ("of: resolver: Fix device node refcount leakage in of_resolve_phandles()") Signed-off-by: Sasha Levin commit b7f5964d03e809d86ff2a8d801cdda0e871ba124 Author: Lad Prabhakar Date: Mon Jan 27 17:31:59 2025 +0000 clk: renesas: r9a07g043: Fix HP clock source for RZ/Five [ Upstream commit 7f22a298d926664b51fcfe2f8ea5feb7f8b79952 ] According to the Rev.1.20 hardware manual for the RZ/Five SoC, the clock source for HP is derived from PLL6 divided by 2. Correct the implementation by configuring HP as a fixed clock source instead of a MUX. The `CPG_PL6_ETH_SSEL' register, which is available on the RZ/G2UL SoC, is not present on the RZ/Five SoC, necessitating this change. Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC") Cc: stable@vger.kernel.org Reported-by: Hien Huynh Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250127173159.34572-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 5053ee6f8d51c3420f401ef59b70f5b02a7307a4 Author: Claudiu Beznea Date: Wed Jan 31 12:29:30 2024 +0200 clk: renesas: r9a07g04[34]: Fix typo for sel_shdi variable [ Upstream commit 46fb5dd9ca289953fa791b2bb060dac7f8002ae0 ] Fix typo for sel_shdi variable. Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240131102930.1841901-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin commit 8213d3a61f211bfa97aeba2a50e6c4f2ef942ece Author: Claudiu Beznea Date: Wed Jan 31 12:29:29 2024 +0200 clk: renesas: r9a07g04[34]: Use SEL_SDHI1_STS status configuration for SD1 mux [ Upstream commit 9b2a11c83859c06233049b134bd8ee974b284559 ] The status configuration for SD1 mux clock is SEL_SDHI1_STS. Fix it. Fixes: 16b86e5c03c5 ("clk: renesas: rzg2l: Refactor SD mux driver") Reported-by: Hien Huynh Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240131102930.1841901-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin commit 50563380f7442c40ace01b2f3feb44a9013733da Author: Claudiu Beznea Date: Fri Oct 6 13:39:57 2023 +0300 clk: renesas: rzg2l: Refactor SD mux driver [ Upstream commit 16b86e5c03c5b3ef35bf5126b35384faa97428f0 ] Refactor SD MUX driver to be able to reuse the same code on RZ/G3S. RZ/G2{L,UL} has a limitation with regards to switching the clock source for SD MUX (MUX clock source has to be switched to 266MHz before switching b/w 533MHz and 400MHz). Rework the handling of this limitation to use a clock notifier that is registered according to platform based initialization data, so the SD MUX code can be reused on RZ/G3S. As RZ/G2{L,UL} and RZ/G3S use different bits in different registers to check if the clock switching has been done, this configuration (register offset, register bits and bitfield width) is now passed through struct cpg_core_clk::sconf (status configuration) from platform specific initialization code. Along with struct cpg_core_clk::sconf the mux table indices are also passed from platform specific initialization code. Also, mux flags are now passed to DEF_SD_MUX() as they will be used later by RZ/G3S. CPG_WEN_BIT macro has been introduced to select properly the WEN bit of various registers. Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20231006103959.197485-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin commit 94c31387f6dcde06f95edd30f6dd686a47f96a6e Author: Claudiu Beznea Date: Fri Sep 29 08:38:56 2023 +0300 clk: renesas: rzg2l: Remove CPG_SDHI_DSEL from generic header [ Upstream commit 3e8008fcf6b7f7c65ad2718c18fb79f37007f1a5 ] Remove CPG_SDHI_DSEL and its bits from the generic header as RZ/G3S has different offset registers and bits for this, thus avoid mixing them. Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230929053915.1530607-10-claudiu.beznea@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin commit 0b78075a9c8f6e67eff46ebd63bb7a61af904e5c Author: Claudiu Beznea Date: Fri Sep 29 08:38:55 2023 +0300 clk: renesas: rzg2l: Add struct clk_hw_data [ Upstream commit 97c1c4ccda76d2919775d748cf223637cf0e82ae ] Add clk_hw_data struct that keeps the core part of the clock data. sd_hw_data embeds a member of type struct clk_hw_data along with other members (in the next commits). This commit prepares the field for refactoring the SD MUX clock driver. Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230929053915.1530607-9-claudiu.beznea@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin commit a70a0ac48bb095f72b49ca2a2d779a2c34a2b413 Author: Claudiu Beznea Date: Tue Sep 12 07:51:34 2023 +0300 clk: renesas: rzg2l: Use u32 for flag and mux_flags [ Upstream commit 897a3e34d6e73d2386715d5c44c57992f2c0eada ] flag and mux_flags are intended to keep bit masks. Use u32 type for it. Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20230912045157.177966-15-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin commit b447885ec9130cf86f355e011dc6b94d6ccfb5b7 Author: Herve Codina Date: Wed Jan 22 10:19:14 2025 +0100 backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() [ Upstream commit 276822a00db3c1061382b41e72cafc09d6a0ec30 ] Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable(). Fixes: ae232e45acf9 ("backlight: add led-backlight driver") Cc: stable@vger.kernel.org Signed-off-by: Herve Codina Link: https://lore.kernel.org/r/20250122091914.309533-1-herve.codina@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit c5a9d6c54d4bf65a7201b1a23a5118271ea7a589 Author: Uwe Kleine-König Date: Wed Mar 8 08:39:38 2023 +0100 backlight: led_bl: Convert to platform remove callback returning void [ Upstream commit c4c4fa57fd3cc00020152baa169337521f90b2ad ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20230308073945.2336302-7-u.kleine-koenig@pengutronix.de Stable-dep-of: 276822a00db3 ("backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()") Signed-off-by: Sasha Levin commit 11f724853e71b04f1736438ecb894073803c53d6 Author: Sergiu Cuciurean Date: Thu Mar 6 18:00:29 2025 -0300 iio: adc: ad7768-1: Fix conversion result sign [ Upstream commit 8236644f5ecb180e80ad92d691c22bc509b747bb ] The ad7768-1 ADC output code is two's complement, meaning that the voltage conversion result is a signed value.. Since the value is a 24 bit one, stored in a 32 bit variable, the sign should be extended in order to get the correct representation. Also the channel description has been updated to signed representation, to match the ADC specifications. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Reviewed-by: David Lechner Reviewed-by: Marcelo Schmitt Signed-off-by: Sergiu Cuciurean Signed-off-by: Jonathan Santos Cc: Link: https://patch.msgid.link/505994d3b71c2aa38ba714d909a68e021f12124c.1741268122.git.Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c13b7cacbc6f158d37b937a848efc77ba56ec238 Author: Jonathan Cameron Date: Mon Feb 17 14:16:12 2025 +0000 iio: adc: ad7768-1: Move setting of val a bit later to avoid unnecessary return value check [ Upstream commit 0af1c801a15225304a6328258efbf2bee245c654 ] The data used is all in local variables so there is no advantage in setting *val = ret with the direct mode claim held. Move it later to after error check. Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250217141630.897334-13-jic23@kernel.org Signed-off-by: Jonathan Cameron Stable-dep-of: 8236644f5ecb ("iio: adc: ad7768-1: Fix conversion result sign") Signed-off-by: Sasha Levin commit c239afce68a2219e4c2a2f709397eee304e17048 Author: Marek Behún Date: Mon Mar 17 18:32:44 2025 +0100 net: dsa: mv88e6xxx: fix VTU methods for 6320 family [ Upstream commit f9a457722cf5e3534be5ffab549d6b49737fca72 ] The VTU registers of the 6320 family use the 6352 semantics, not 6185. Fix it. Fixes: b8fee9571063 ("net: dsa: mv88e6xxx: add VLAN Get Next support") Signed-off-by: Marek Behún Cc: # 5.15.x Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-2-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58c14a5e2a78da692840bfbbcd7e1ff7253eb165 Author: Marek Behún Date: Mon Mar 17 18:32:49 2025 +0100 net: dsa: mv88e6xxx: fix internal PHYs for 6320 family [ Upstream commit 52fdc41c3278c981066a461d03d5477ebfcf270c ] Fix internal PHYs definition for the 6320 family, which has only 2 internal PHYs (on ports 3 and 4). Fixes: bc3931557d1d ("net: dsa: mv88e6xxx: Add number of internal PHYs") Signed-off-by: Marek Behún Cc: # 6.6.x Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-7-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4db3e956ca3870e64154b9b22bb3fd805106d6af Author: Alexis Lothoré Date: Mon May 29 10:02:43 2023 +0200 net: dsa: mv88e6xxx: add field to specify internal phys layout [ Upstream commit 3ba89b28adb21a5d5d78e905e2c3972816606bb4 ] mv88e6xxx currently assumes that switch equipped with internal phys have those phys mapped contiguously starting from port 0 (see mv88e6xxx_phy_is_internal). However, some switches have internal PHYs but NOT starting from port 0. For example 88e6393X, 88E6193X and 88E6191X have integrated PHYs available on ports 1 to 8 To properly support this offset, add a new field to allow specifying an internal PHYs layout. If field is not set, default layout is assumed (start at port 0) Signed-off-by: Alexis Lothoré Reviewed-by: Andrew Lunn Signed-off-by: Jakub Kicinski Stable-dep-of: 52fdc41c3278 ("net: dsa: mv88e6xxx: fix internal PHYs for 6320 family") Signed-off-by: Sasha Levin commit 7cdba14d7554fd66ee43e35d77aa02a30480f417 Author: Alexis Lothoré Date: Mon May 29 10:02:41 2023 +0200 net: dsa: mv88e6xxx: pass directly chip structure to mv88e6xxx_phy_is_internal [ Upstream commit ca345931907ff1893f02f5fe1349b16c9fc27e4c ] Since this function is a simple helper, we do not need to pass a full dsa_switch structure, we can directly pass the mv88e6xxx_chip structure. Doing so will allow to share this function with any other function not manipulating dsa_switch structure but needing info about number of internal phys Signed-off-by: Alexis Lothoré Reviewed-by: Russell King (Oracle) Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Stable-dep-of: 52fdc41c3278 ("net: dsa: mv88e6xxx: fix internal PHYs for 6320 family") Signed-off-by: Sasha Levin commit 3edbf0fd90ff9d49b318fd176acd8b20733fc037 Author: Russell King (Oracle) Date: Thu May 25 11:38:50 2023 +0100 net: dsa: mv88e6xxx: move link forcing to mac_prepare/mac_finish [ Upstream commit 267d7692f6cd5c9b8796324cdd54db594ca8d3e4 ] Move the link forcing out of mac_config() and into the mac_prepare() and mac_finish() methods. This results in no change to the order in which these operations are performed, but does mean when we convert mv88e6xxx to phylink_pcs support, we will continue to preserve this ordering. Reviewed-by: Andrew Lunn Signed-off-by: Russell King (Oracle) Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: 52fdc41c3278 ("net: dsa: mv88e6xxx: fix internal PHYs for 6320 family") Signed-off-by: Sasha Levin commit f27b1e1fd32905f1de06f13b02fac2ae6d1382af Author: Russell King (Oracle) Date: Thu May 25 11:38:44 2023 +0100 net: dsa: add support for mac_prepare() and mac_finish() calls [ Upstream commit dd805cf3e80e038aeb06902399ce9bd6fafb4ff3 ] Add DSA support for the phylink mac_prepare() and mac_finish() calls. These were introduced as part of the PCS support to allow MACs to perform preparatory steps prior to configuration, and finalisation steps after the MAC and PCS has been configured. Introducing phylink_pcs support to the mv88e6xxx DSA driver needs some code moved out of its mac_config() stage into the mac_prepare() and mac_finish() stages, and this commit facilitates such code in DSA drivers. Reviewed-by: Andrew Lunn Signed-off-by: Russell King (Oracle) Reviewed-by: Simon Horman Signed-off-by: David S. Miller Stable-dep-of: 52fdc41c3278 ("net: dsa: mv88e6xxx: fix internal PHYs for 6320 family") Signed-off-by: Sasha Levin commit 9369d414ee70f4c76a7e100f2508e1be873641d0 Author: Vladimir Oltean Date: Wed Mar 15 17:38:43 2023 +0100 net: dsa: mv88e6xxx: don't dispose of Global2 IRQ mappings from mdiobus code [ Upstream commit b1a2de9ccfe63b50e493ebb57b85beb5785200c7 ] irq_find_mapping() does not need irq_dispose_mapping(), only irq_create_mapping() does. Calling irq_dispose_mapping() from mv88e6xxx_g2_irq_mdio_free() and from the error path of mv88e6xxx_g2_irq_mdio_setup() effectively means that the mdiobus logic (for internal PHY interrupts) is disposing of a hwirq->virq mapping which it is not responsible of (but instead, the function pair mv88e6xxx_g2_irq_setup() + mv88e6xxx_g2_irq_free() is). With the current code structure, this isn't such a huge problem, because mv88e6xxx_g2_irq_mdio_free() is called relatively close to the real owner of the IRQ mappings: mv88e6xxx_remove() -> mv88e6xxx_unregister_switch() -> mv88e6xxx_mdios_unregister() -> mv88e6xxx_g2_irq_mdio_free() -> mv88e6xxx_g2_irq_free() and the switch isn't 'live' in any way such that it would be able of generating interrupts at this point (mv88e6xxx_unregister_switch() has been called). However, there is a desire to split mv88e6xxx_mdios_unregister() and mv88e6xxx_g2_irq_free() such that mv88e6xxx_mdios_unregister() only gets called from mv88e6xxx_teardown(). This is much more problematic, as can be seen below. In a cross-chip scenario (say 3 switches d0032004.mdio-mii:10, d0032004.mdio-mii:11 and d0032004.mdio-mii:12 which form a single DSA tree), it is possible to unbind the device driver from a single switch (say d0032004.mdio-mii:10). When that happens, mv88e6xxx_remove() will be called for just that one switch, and this will call mv88e6xxx_unregister_switch() which will tear down the entire tree (calling mv88e6xxx_teardown() for all 3 switches). Assuming mv88e6xxx_mdios_unregister() was moved to mv88e6xxx_teardown(), at this stage, all 3 switches will have called irq_dispose_mapping() on their mdiobus virqs. When we bind again the device driver to d0032004.mdio-mii:10, mv88e6xxx_probe() is called for it, which calls dsa_register_switch(). The DSA tree is now complete again, and mv88e6xxx_setup() is called for all 3 switches. Also assuming that mv88e6xxx_mdios_register() is moved to mv88e6xxx_setup() (the 2 assumptions go together), at this point, d0032004.mdio-mii:11 and d0032004.mdio-mii:12 don't have an IRQ mapping for the internal PHYs anymore, as they've disposed of it in mv88e6xxx_teardown(). Whereas switch d0032004.mdio-mii:10 has re-created it, because its code path comes from mv88e6xxx_probe(). Simply put, this change prepares the driver to handle the movement of mv88e6xxx_mdios_register() to mv88e6xxx_setup() for cross-chip DSA trees. Also, the code being deleted was partially wrong anyway (in a way which may have hidden this other issue). mv88e6xxx_g2_irq_mdio_setup() populates bus->irq[] starting with offset chip->info->phy_base_addr, but the teardown path doesn't apply that offset too. So it disposes of virq 0 for phy = [ 0, phy_base_addr ). All switch families have phy_base_addr = 0, except for MV88E6141 and MV88E6341 which have it as 0x10. I guess those families would have happened to work by mistake in cross-chip scenarios too. I'm deleting the body of mv88e6xxx_g2_irq_mdio_free() but leaving its call sites and prototype in place. This is because, if we ever need to add back some teardown procedure in the future, it will be perhaps error-prone to deduce the proper call sites again. Whereas like this, no extra code should get generated, it shouldn't bother anybody. Signed-off-by: Vladimir Oltean Signed-off-by: Klaus Kudielka Tested-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Stable-dep-of: 52fdc41c3278 ("net: dsa: mv88e6xxx: fix internal PHYs for 6320 family") Signed-off-by: Sasha Levin commit 0882b47507b0ef19d70131f7cdc6acef97a1150c Author: Haoxiang Li Date: Mon Feb 24 18:15:27 2025 +0800 auxdisplay: hd44780: Fix an API misuse in hd44780.c [ Upstream commit 9b98a7d2e5f4e2beeff88f6571da0cdc5883c7fb ] Variable allocated by charlcd_alloc() should be released by charlcd_free(). The following patch changed kfree() to charlcd_free() to fix an API misuse. Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 4b9c5e6e8926f6beabff572a1a178f74a3e566d0 Author: Uwe Kleine-König Date: Mon Mar 11 22:59:23 2024 +0100 auxdisplay: hd44780: Convert to platform remove callback returning void [ Upstream commit 9ea02f7cc39d484d16e8a14f3713fefcd33407c0 ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Stable-dep-of: 9b98a7d2e5f4 ("auxdisplay: hd44780: Fix an API misuse in hd44780.c") Signed-off-by: Sasha Levin commit 6854c87ac823181c810f8c07489ba543260c0023 Author: Steven Rostedt Date: Thu Mar 27 19:53:11 2025 -0400 tracing: Verify event formats that have "%*p.." [ Upstream commit ea8d7647f9ddf1f81e2027ed305299797299aa03 ] The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of "%*pbl". Link: https://lore.kernel.org/all/bcba4d76-2c3f-4d11-baf0-02905db953dd@oracle.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 5013f454a352c ("tracing: Add check of trace event print fmts for dereferencing pointers") Link: https://lore.kernel.org/20250327195311.2d89ec66@gandalf.local.home Reported-by: Libo Chen Reviewed-by: Libo Chen Tested-by: Libo Chen Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 480b9fc4b2401c2130c28ac4fae0cb2095465f03 Author: Steven Rostedt Date: Tue Oct 22 19:36:28 2024 +0000 tracing: Add __print_dynamic_array() helper [ Upstream commit e52750fb1458ae9ea5860a08ed7a149185bc5b97 ] When printing a dynamic array in a trace event, the method is rather ugly. It has the format of: __print_array(__get_dynamic_array(array), __get_dynmaic_array_len(array) / el_size, el_size) Since dynamic arrays are known to the tracing infrastructure, create a helper macro that does the above for you. __print_dynamic_array(array, el_size) Which would expand to the same output. Signed-off-by: Steven Rostedt (Google) Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Qiuxu Zhuo Link: https://lore.kernel.org/r/20241022194158.110073-3-avadhut.naik@amd.com Stable-dep-of: ea8d7647f9dd ("tracing: Verify event formats that have "%*p.."") Signed-off-by: Sasha Levin commit 247feaa17419eb25b1354a3071334aac6f8e0ebd Author: Steven Rostedt (Google) Date: Fri Feb 23 15:28:27 2024 -0500 tracing: Add __string_len() example [ Upstream commit dd6ae6d90a84d4bec49887c7aa2b22aa1c8b2897 ] There's no example code that uses __string_len(), and since the sample code is used for testing the event logic, add a use case. Link: https://lore.kernel.org/linux-trace-kernel/20240223152827.5f9f78e2@gandalf.local.home Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Signed-off-by: Steven Rostedt (Google) Stable-dep-of: ea8d7647f9dd ("tracing: Verify event formats that have "%*p.."") Signed-off-by: Sasha Levin commit 41abc05ab8cd44a51f8ef3c7fe252be730c871d7 Author: Steven Rostedt (Google) Date: Tue Dec 13 22:12:27 2022 -0500 tracing: Fix cpumask() example typo [ Upstream commit eb9d58947d40699d93e5e69e1ddc54e41da7e132 ] The sample code for using cpumask used the wrong field for the __get_cpumask() helper. It used "cpus" which is the bitmask (but would still give a proper example) instead of the "cpum" that was there to be used. Although it produces the same output, fix it, because it's an example and is confusing in how to properly use the cpumask() macro. Link: https://lore.kernel.org/linux-trace-kernel/20221213221227.56560374@gandalf.local.home Cc: Andrew Morton Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Stable-dep-of: ea8d7647f9dd ("tracing: Verify event formats that have "%*p.."") Signed-off-by: Sasha Levin commit 3c8a30f95bcba9bf16cca5a6df11d870969d1157 Author: Steven Rostedt (Google) Date: Fri Oct 14 08:04:56 2022 -0400 tracing: Add __cpumask to denote a trace event field that is a cpumask_t [ Upstream commit 8230f27b1ccc4b8976c137e3d6d690f9d4ffca8d ] The trace events have a __bitmask field that can be used for anything that requires bitmasks. Although currently it is only used for CPU masks, it could be used in the future for any type of bitmasks. There is some user space tooling that wants to know if a field is a CPU mask and not just some random unsigned long bitmask. Introduce "__cpumask()" helper functions that work the same as the current __bitmask() helpers but displays in the format file: field:__data_loc cpumask_t *[] mask; offset:36; size:4; signed:0; Instead of: field:__data_loc unsigned long[] mask; offset:32; size:4; signed:0; The main difference is the type. Instead of "unsigned long" it is "cpumask_t *". Note, this type field needs to be a real type in the __dynamic_array() logic that both __cpumask and__bitmask use, but the comparison field requires it to be a scalar type whereas cpumask_t is a structure (non-scalar). But everything works when making it a pointer. Valentin added changes to remove the need of passing in "nr_bits" and the __cpumask will always use nr_cpumask_bits as its size. Link: https://lkml.kernel.org/r/20221014080456.1d32b989@rorschach.local.home Requested-by: Valentin Schneider Reviewed-by: Valentin Schneider Signed-off-by: Valentin Schneider Signed-off-by: Steven Rostedt (Google) Stable-dep-of: ea8d7647f9dd ("tracing: Verify event formats that have "%*p.."") Signed-off-by: Sasha Levin commit 7c2f874c63a1a1f08f5cc86994e6719a22b43666 Author: Thorsten Leemhuis Date: Wed Oct 16 16:18:41 2024 +0200 module: sign with sha512 instead of sha1 by default commit f3b93547b91ad849b58eb5ab2dd070950ad7beb3 upstream. Switch away from using sha1 for module signing by default and use the more modern sha512 instead, which is what among others Arch, Fedora, RHEL, and Ubuntu are currently using for their kernels. Sha1 has not been considered secure against well-funded opponents since 2005[1]; since 2011 the NIST and other organizations furthermore recommended its replacement[2]. This is why OpenSSL on RHEL9, Fedora Linux 41+[3], and likely some other current and future distributions reject the creation of sha1 signatures, which leads to a build error of allmodconfig configurations: 80A20474797F0000:error:03000098:digital envelope routines:do_sigver_init:invalid digest:crypto/evp/m_sigver.c:342: make[4]: *** [.../certs/Makefile:53: certs/signing_key.pem] Error 1 make[4]: *** Deleting file 'certs/signing_key.pem' make[4]: *** Waiting for unfinished jobs.... make[3]: *** [.../scripts/Makefile.build:478: certs] Error 2 make[2]: *** [.../Makefile:1936: .] Error 2 make[1]: *** [.../Makefile:224: __sub-make] Error 2 make[1]: Leaving directory '...' make: *** [Makefile:224: __sub-make] Error 2 This change makes allmodconfig work again and sets a default that is more appropriate for current and future users, too. Link: https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html [1] Link: https://csrc.nist.gov/projects/hash-functions [2] Link: https://fedoraproject.org/wiki/Changes/OpenSSLDistrustsha1SigVer [3] Signed-off-by: Thorsten Leemhuis Reviewed-by: Sami Tolvanen Tested-by: kdevops [0] Link: https://github.com/linux-kdevops/linux-modules-kpd/actions/runs/11420092929/job/31775404330 [0] Link: https://lore.kernel.org/r/52ee32c0c92afc4d3263cea1f8a1cdc809728aff.1729088288.git.linux@leemhuis.info Signed-off-by: Petr Pavlu Signed-off-by: Greg Kroah-Hartman