commit 19fc50ced9e26871dd30d2cb57274badd2a36453 Author: Alexandre Frade Date: Thu May 29 14:04:18 2025 +0000 Linux 6.12.31-rt-xanmod1 Signed-off-by: Alexandre Frade commit b3718f77512b3e7e8f37ff6fe4eb23f76e95b0c8 Merge: 96c2e3620b94 877ad8fdef9b Author: Alexandre Frade Date: Thu May 29 14:02:57 2025 +0000 Merge branch '6.12' into 6.12-rt commit 877ad8fdef9b7698317eb75a8ad21283fb4bc076 Author: Alexandre Frade Date: Thu May 29 13:57:54 2025 +0000 Linux 6.12.31-xanmod1 Signed-off-by: Alexandre Frade commit bfd36776cffafcfd7fa2d48b2be8b894465647b8 Merge: e97e9ef4704e df3f6d10f353 Author: Alexandre Frade Date: Thu May 29 13:51:15 2025 +0000 Merge tag 'v6.12.31' into 6.12 This is the 6.12.31 stable release commit df3f6d10f353de274cc7c87f52dba5d26f185393 Author: Greg Kroah-Hartman Date: Thu May 29 11:03:27 2025 +0200 Linux 6.12.31 Link: https://lore.kernel.org/r/20250527162445.028718347@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Harshit Mogalapalli Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Mark Brown Tested-by: Brett Mastbergen Tested-by: Markus Reichelt Signed-off-by: Greg Kroah-Hartman commit 85fb1edd059bf7ac3070ec98b64486fc54da3b65 Author: Thomas Zimmermann Date: Wed Apr 16 08:57:45 2025 +0200 drm/gem: Internally test import_attach for imported objects commit 8260731ccad0451207b45844bb66eb161a209218 upstream. Test struct drm_gem_object.import_attach to detect imported objects. During object clenanup, the dma_buf field might be NULL. Testing it in an object's free callback then incorrectly does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). v3: - only test for import_attach (Boris) v2: - use import_attach.dmabuf instead of dma_buf (Christian) Signed-off-by: Thomas Zimmermann Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andyshrk@163.com/ Tested-by: Andy Yan Cc: Thomas Zimmermann Cc: Anusha Srivatsa Cc: Christian König Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Simona Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Boris Brezillon Reviewed-by: Simona Vetter Link: https://lore.kernel.org/r/20250416065820.26076-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit ee2a06bbbb8a01e40abaf1f0e1d49aaf78a55c9e Author: Balbir Singh Date: Tue Apr 1 11:07:52 2025 +1100 x86/mm/init: Handle the special case of device private pages in add_pages(), to not increase max_pfn and trigger dma_addressing_limited() bounce buffers bounce buffers commit 7170130e4c72ce0caa0cb42a1627c635cc262821 upstream. As Bert Karwatzki reported, the following recent commit causes a performance regression on AMD iGPU and dGPU systems: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") It exposed a bug with nokaslr and zone device interaction. The root cause of the bug is that, the GPU driver registers a zone device private memory region. When KASLR is disabled or the above commit is applied, the direct_map_physmem_end is set to much higher than 10 TiB typically to the 64TiB address. When zone device private memory is added to the system via add_pages(), it bumps up the max_pfn to the same value. This causes dma_addressing_limited() to return true, since the device cannot address memory all the way up to max_pfn. This caused a regression for games played on the iGPU, as it resulted in the DMA32 zone being used for GPU allocations. Fix this by not bumping up max_pfn on x86 systems, when pgmap is passed into add_pages(). The presence of pgmap is used to determine if device private memory is being added via add_pages(). More details: devm_request_mem_region() and request_free_mem_region() request for device private memory. iomem_resource is passed as the base resource with start and end parameters. iomem_resource's end depends on several factors, including the platform and virtualization. On x86 for example on bare metal, this value is set to boot_cpu_data.x86_phys_bits. boot_cpu_data.x86_phys_bits can change depending on support for MKTME. By default it is set to the same as log2(direct_map_physmem_end) which is 46 to 52 bits depending on the number of levels in the page table. The allocation routines used iomem_resource's end and direct_map_physmem_end to figure out where to allocate the region. [ arch/powerpc is also impacted by this problem, but this patch does not fix the issue for PowerPC. ] Testing: 1. Tested on a virtual machine with test_hmm for zone device inseration 2. A previous version of this patch was tested by Bert, please see: https://lore.kernel.org/lkml/d87680bab997fdc9fb4e638983132af235d9a03a.camel@web.de/ [ mingo: Clarified the comments and the changelog. ] Reported-by: Bert Karwatzki Tested-by: Bert Karwatzki Fixes: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") Signed-off-by: Balbir Singh Signed-off-by: Ingo Molnar Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Andrew Morton Cc: Christoph Hellwig Cc: Pierre-Eric Pelloux-Prayer Cc: Alex Deucher Cc: Christian König Cc: David Airlie Cc: Simona Vetter Link: https://lore.kernel.org/r/20250401000752.249348-1-balbirs@nvidia.com Signed-off-by: Greg Kroah-Hartman commit ae0d63ec390534606733cd63ef6d0484a04efd92 Author: Nathan Chancellor Date: Wed Mar 19 09:08:01 2025 -0700 i3c: master: svc: Fix implicit fallthrough in svc_i3c_master_ibi_work() commit e8d2d287e26d9bd9114cf258a123a6b70812442e upstream. Clang warns (or errors with CONFIG_WERROR=y): drivers/i3c/master/svc-i3c-master.c:596:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] 596 | default: | ^ drivers/i3c/master/svc-i3c-master.c:596:2: note: insert 'break;' to avoid fall-through 596 | default: | ^ | break; 1 error generated. Clang is a little more pedantic than GCC, which does not warn when falling through to a case that is just break or return. Clang's version is more in line with the kernel's own stance in deprecated.rst, which states that all switch/case blocks must end in either break, fallthrough, continue, goto, or return. Add the missing break to silence the warning. Fixes: 0430bf9bc1ac ("i3c: master: svc: Fix missing STOP for master request") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250319-i3c-fix-clang-fallthrough-v1-1-d8e02be1ef5c@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 73c4707510f27f61b62303923814f624583bedff Author: Dan Carpenter Date: Wed Mar 19 10:05:47 2025 +0300 pinctrl: tegra: Fix off by one in tegra_pinctrl_get_group() commit 5a062c3c3b82004766bc3ece82b594d337076152 upstream. This should be >= pmx->soc->ngroups instead of > to avoid an out of bounds access. The pmx->soc->groups[] array is allocated in tegra_pinctrl_probe(). Fixes: c12bfa0fee65 ("pinctrl-tegra: Restore SFSEL bit when freeing pins") Signed-off-by: Dan Carpenter Reviewed-by: Kunwu Chan Link: https://lore.kernel.org/82b40d9d-b437-42a9-9eb3-2328aa6877ac@stanley.mountain Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit ecb9d3123bef7307a5ad16d05ce65fe9d9cf8afb Author: Arnd Bergmann Date: Fri Mar 14 17:02:44 2025 +0100 watchdog: aspeed: fix 64-bit division commit 48a136639ec233614a61653e19f559977d5da2b5 upstream. On 32-bit architectures, the new calculation causes a build failure: ld.lld-21: error: undefined symbol: __aeabi_uldivmod Since neither value is ever larger than a register, cast both sides into a uintptr_t. Fixes: 5c03f9f4d362 ("watchdog: aspeed: Update bootstatus handling") Signed-off-by: Arnd Bergmann Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250314160248.502324-1-arnd@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit c3e1091eb054cf62ed19b60df7abde03bbbffaae Author: Amber Lin Date: Wed Mar 12 21:14:43 2025 -0400 drm/amdkfd: Correct F8_MODE for gfx950 commit 0c7e053448945e5a4379dc4396c762d7422b11ca upstream. Correct F8_MODE setting for gfx950 that was removed Fixes: 61972cd93af7 ("drm/amdkfd: Set per-process flags only once for gfx9/10/11/12") Signed-off-by: Amber Lin Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a8a34fbf915dd5c472ada04e7c969da65f7d693a Author: Geert Uytterhoeven Date: Tue Mar 4 20:06:11 2025 +0100 serial: sh-sci: Save and restore more registers commit 81100b9a7b0515132996d62a7a676a77676cb6e3 upstream. On (H)SCIF with a Baud Rate Generator for External Clock (BRG), there are multiple ways to configure the requested serial speed. If firmware uses a different method than Linux, and if any debug info is printed after the Bit Rate Register (SCBRR) is restored, but before termios is reconfigured (which configures the alternative method), the system may lock-up during resume. Fix this by saving and restoring the contents of the BRG Frequency Division (SCDL) and Clock Select (SCCKS) registers as well. Also save and restore the HSCIF's Sampling Rate Register (HSSRR), which configures the sampling point, and the SCIFA/SCIFB's Serial Port Control and Data Registers (SCPCR/SCPDR), which configure the optional control flow signals. After this, all registers that are not saved/restored are either: - read-only, - write-only, - status registers containing flags with clear-after-set semantics, - FIFO Data Count Trigger registers, which do not matter much for the serial console. Fixes: 22a6984c5b5df8ea ("serial: sh-sci: Update the suspend/resume support") Signed-off-by: Geert Uytterhoeven Tested-by: Claudiu Beznea Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/11c2eab45d48211e75d8b8202cce60400880fe55.1741114989.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 80eb73778debad263e53843cad276dfe92924f66 Author: Eduard Zingerman Date: Mon Feb 24 16:38:38 2025 -0800 bpf: abort verification if env->cur_state->loop_entry != NULL commit f3c2d243a36ef23be07bc2bce7c6a5cb6e07d9e3 upstream. In addition to warning abort verification with -EFAULT. If env->cur_state->loop_entry != NULL something is irrecoverably buggy. Fixes: bbbc02b7445e ("bpf: copy_verifier_state() should copy 'loop_entry' field") Suggested-by: Andrii Nakryiko Signed-off-by: Eduard Zingerman Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20250225003838.135319-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit fdee1dc816b4c50c04c34cb8dec5f704e7e75189 Author: Ovidiu Bunea Date: Mon Feb 3 15:43:32 2025 -0500 drm/amd/display: Exit idle optimizations before accessing PHY commit c488967488d7eff7b9c527d5469c424c15377502 upstream. [why & how] By default, DCN HW is in idle optimized state which does not allow access to PHY registers. If BIOS powers up the DCN, it is fine because they will power up everything. Only exit idle optimized state when not taking control from VBIOS. Fixes: be704e5ef4bd ("Revert "drm/amd/display: Exit idle optimizations before attempt to access PHY"") Reviewed-by: Charlene Liu Signed-off-by: Ovidiu Bunea Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit dd8a734155ae28094d27b96c00a478fa0ee6d5d7 Author: Nathan Chancellor Date: Wed Apr 30 15:56:34 2025 -0700 kbuild: Properly disable -Wunterminated-string-initialization for clang commit 4f79eaa2ceac86a0e0f304b0bab556cca5bf4f30 upstream. Clang and GCC have different behaviors around disabling warnings included in -Wall and -Wextra and the order in which flags are specified, which is exposed by clang's new support for -Wunterminated-string-initialization. $ cat test.c const char foo[3] = "FOO"; const char bar[3] __attribute__((__nonstring__)) = "BAR"; $ clang -fsyntax-only -Wextra test.c test.c:1:21: warning: initializer-string for character array is too long, array size is 3 but initializer has size 4 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ clang -fsyntax-only -Wextra -Wno-unterminated-string-initialization test.c $ clang -fsyntax-only -Wno-unterminated-string-initialization -Wextra test.c test.c:1:21: warning: initializer-string for character array is too long, array size is 3 but initializer has size 4 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ gcc -fsyntax-only -Wextra test.c test.c:1:21: warning: initializer-string for array of ‘char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (4 chars into 3 available) [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ gcc -fsyntax-only -Wextra -Wno-unterminated-string-initialization test.c $ gcc -fsyntax-only -Wno-unterminated-string-initialization -Wextra test.c Move -Wextra up right below -Wall in Makefile.extrawarn to ensure these flags are at the beginning of the warning options list. Move the couple of warning options that have been added to the main Makefile since commit e88ca24319e4 ("kbuild: consolidate warning flags in scripts/Makefile.extrawarn") to scripts/Makefile.extrawarn after -Wall / -Wextra to ensure they get properly disabled for all compilers. Fixes: 9d7a0577c9db ("gcc-15: disable '-Wunterminated-string-initialization' entirely for now") Link: https://github.com/llvm/llvm-project/issues/10359 Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 3f856d5d84467c7fba0bf3cca405089c497e37eb Author: Linus Torvalds Date: Wed Apr 23 10:08:29 2025 -0700 Fix mis-uses of 'cc-option' for warning disablement commit a79be02bba5c31f967885c7f3bf3a756d77d11d9 upstream. This was triggered by one of my mis-uses causing odd build warnings on sparc in linux-next, but while figuring out why the "obviously correct" use of cc-option caused such odd breakage, I found eight other cases of the same thing in the tree. The root cause is that 'cc-option' doesn't work for checking negative warning options (ie things like '-Wno-stringop-overflow') because gcc will silently accept options it doesn't recognize, and so 'cc-option' ends up thinking they are perfectly fine. And it all works, until you have a situation where _another_ warning is emitted. At that point the compiler will go "Hmm, maybe the user intended to disable this warning but used that wrong option that I didn't recognize", and generate a warning for the unrecognized negative option. Which explains why we have several cases of this in the tree: the 'cc-option' test really doesn't work for this situation, but most of the time it simply doesn't matter that ity doesn't work. The reason my recently added case caused problems on sparc was pointed out by Thomas Weißschuh: the sparc build had a previous explicit warning that then triggered the new one. I think the best fix for this would be to make 'cc-option' a bit smarter about this sitation, possibly by adding an intentional warning to the test case that then triggers the unrecognized option warning reliably. But the short-term fix is to replace 'cc-option' with an existing helper designed for this exact case: 'cc-disable-warning', which picks the negative warning but uses the positive form for testing the compiler support. Reported-by: Stephen Rothwell Link: https://lore.kernel.org/all/20250422204718.0b4e3f81@canb.auug.org.au/ Explained-by: Thomas Weißschuh Signed-off-by: Linus Torvalds Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit d66cf772bebd789448121cdfc42734fb042c9c4b Author: Linus Torvalds Date: Sun Apr 20 15:30:53 2025 -0700 gcc-15: disable '-Wunterminated-string-initialization' entirely for now commit 9d7a0577c9db35c4cc52db90bc415ea248446472 upstream. From: Linus Torvalds I had left the warning around but as a non-fatal error to get my gcc-15 builds going, but fixed up some of the most annoying warning cases so that it wouldn't be *too* verbose. Because I like the _concept_ of the warning, even if I detested the implementation to shut it up. It turns out the implementation to shut it up is even more broken than I thought, and my "shut up most of the warnings" patch just caused fatal errors on gcc-14 instead. I had tested with clang, but when I upgrade my development environment, I try to do it on all machines because I hate having different systems to maintain, and hadn't realized that gcc-14 now had issues. The ACPI case is literally why I wanted to have a *type* that doesn't trigger the warning (see commit d5d45a7f2619: "gcc-15: make 'unterminated string initialization' just a warning"), instead of marking individual places as "__nonstring". But gcc-14 doesn't like that __nonstring location that shut gcc-15 up, because it's on an array of char arrays, not on one single array: drivers/acpi/tables.c:399:1: error: 'nonstring' attribute ignored on objects of type 'const char[][4]' [-Werror=attributes] 399 | static const char table_sigs[][ACPI_NAMESEG_SIZE] __initconst __nonstring = { | ^~~~~~ and my attempts to nest it properly with a type had failed, because of how gcc doesn't like marking the types as having attributes, only symbols. There may be some trick to it, but I was already annoyed by the bad attribute design, now I'm just entirely fed up with it. I wish gcc had a proper way to say "this type is a *byte* array, not a string". The obvious thing would be to distinguish between "char []" and an explicitly signed "unsigned char []" (as opposed to an implicitly unsigned char, which is typically an architecture-specific default, but for the kernel is universal thanks to '-funsigned-char'). But any "we can typedef a 8-bit type to not become a string just because it's an array" model would be fine. But "__attribute__((nonstring))" is sadly not that sane model. Reported-by: Chris Clayton Fixes: 4b4bd8c50f48 ("gcc-15: acpi: sprinkle random '__nonstring' crumbles around") Fixes: d5d45a7f2619 ("gcc-15: make 'unterminated string initialization' just a warning") Signed-off-by: Linus Torvalds [nathan: drivers/acpi diff dropped due to lack of 4b4bd8c50f48 in stable] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 9f58537e9b8f07d56aca68308dc73db60fbc7ad3 Author: Linus Torvalds Date: Sun Apr 20 10:33:23 2025 -0700 gcc-15: make 'unterminated string initialization' just a warning commit d5d45a7f26194460964eb5677a9226697f7b7fdd upstream. gcc-15 enabling -Wunterminated-string-initialization in -Wextra by default was done with the best intentions, but the warning is still quite broken. What annoys me about the warning is that this is a very traditional AND CORRECT way to initialize fixed byte arrays in C: unsigned char hex[16] = "0123456789abcdef"; and we use this all over the kernel. And the warning is fine, but gcc developers apparently never made a reasonable way to disable it. As is (sadly) tradition with these things. Yes, there's "__attribute__((nonstring))", and we have a macro to make that absolutely disgusting syntax more palatable (ie the kernel syntax for that monstrosity is just "__nonstring"). But that attribute is misdesigned. What you'd typically want to do is tell the compiler that you are using a type that isn't a string but a byte array, but that doesn't work at all: warning: ‘nonstring’ attribute does not apply to types [-Wattributes] and because of this fundamental mis-design, you then have to mark each instance of that pattern. This is particularly noticeable in our ACPI code, because ACPI has this notion of a 4-byte "type name" that gets used all over, and is exactly this kind of byte array. This is a sad oversight, because the warning is useful, but really would be so much better if gcc had also given a sane way to indicate that we really just want a byte array type at a type level, not the broken "each and every array definition" level. So now instead of creating a nice "ACPI name" type using something like typedef char acpi_name_t[4] __nonstring; we have to do things like char name[ACPI_NAMESEG_SIZE] __nonstring; in every place that uses this concept and then happens to have the typical initializers. This is annoying me mainly because I think the warning _is_ a good warning, which is why I'm not just turning it off in disgust. But it is hampered by this bad implementation detail. [ And obviously I'm doing this now because system upgrades for me are something that happen in the middle of the release cycle: don't do it before or during travel, or just before or during the busy merge window period. ] Signed-off-by: Linus Torvalds Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit d28b0305f711e5b1f30812e4d62169835f481e6b Author: Raag Jadav Date: Wed Feb 12 11:55:02 2025 +0530 err.h: move IOMEM_ERR_PTR() to err.h commit 18311a766c587fc69b1806f1d5943305903b7e6e upstream. Since IOMEM_ERR_PTR() macro deals with an error pointer, a better place for it is err.h. This helps avoid dependency on io.h for the users that don't need it. Suggested-by: Andy Shevchenko Signed-off-by: Raag Jadav Acked-by: Arnd Bergmann Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 96537d8c67e5e5025221c7f397bddb7ee927d66c Author: Larisa Grigore Date: Thu May 22 15:51:32 2025 +0100 spi: spi-fsl-dspi: Reset SR flags before sending a new message [ Upstream commit 7aba292eb15389073c7f3bd7847e3862dfdf604d ] If, in a previous transfer, the controller sends more data than expected by the DSPI target, SR.RFDF (RX FIFO is not empty) will remain asserted. When flushing the FIFOs at the beginning of a new transfer (writing 1 into MCR.CLR_TXF and MCR.CLR_RXF), SR.RFDF should also be cleared. Otherwise, when running in target mode with DMA, if SR.RFDF remains asserted, the DMA callback will be fired before the controller sends any data. Take this opportunity to reset all Status Register fields. Fixes: 5ce3cc567471 ("spi: spi-fsl-dspi: Provide support for DSPI slave mode operation (Vybryd vf610)") Signed-off-by: Larisa Grigore Signed-off-by: James Clark Link: https://patch.msgid.link/20250522-james-nxp-spi-v2-3-bea884630cfb@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b1781bd47e6d40b29d2cbb39e6b48b837e2dfad0 Author: Bogdan-Gabriel Roman Date: Thu May 22 15:51:31 2025 +0100 spi: spi-fsl-dspi: Halt the module after a new message transfer [ Upstream commit 8a30a6d35a11ff5ccdede7d6740765685385a917 ] The XSPI mode implementation in this driver still uses the EOQ flag to signal the last word in a transmission and deassert the PCS signal. However, at speeds lower than ~200kHZ, the PCS signal seems to remain asserted even when SR[EOQF] = 1 indicates the end of a transmission. This is a problem for target devices which require the deassertation of the PCS signal between transfers. Hence, this commit 'forces' the deassertation of the PCS by stopping the module through MCR[HALT] after completing a new transfer. According to the reference manual, the module stops or transitions from the Running state to the Stopped state after the current frame, when any one of the following conditions exist: - The value of SR[EOQF] = 1. - The chip is in Debug mode and the value of MCR[FRZ] = 1. - The value of MCR[HALT] = 1. This shouldn't be done if the last transfer in the message has cs_change set. Fixes: ea93ed4c181b ("spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI mode") Signed-off-by: Bogdan-Gabriel Roman Signed-off-by: Larisa Grigore Signed-off-by: James Clark Link: https://patch.msgid.link/20250522-james-nxp-spi-v2-2-bea884630cfb@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b9fbbcf61e7c7a00def2ca3e8b91a19dba096102 Author: Larisa Grigore Date: Thu May 22 15:51:30 2025 +0100 spi: spi-fsl-dspi: restrict register range for regmap access [ Upstream commit 283ae0c65e9c592f4a1ba4f31917f5e766da7f31 ] DSPI registers are NOT continuous, some registers are reserved and accessing them from userspace will trigger external abort, add regmap register access table to avoid below abort. For example on S32G: # cat /sys/kernel/debug/regmap/401d8000.spi/registers Internal error: synchronous external abort: 96000210 1 PREEMPT SMP ... Call trace: regmap_mmio_read32le+0x24/0x48 regmap_mmio_read+0x48/0x70 _regmap_bus_reg_read+0x38/0x48 _regmap_read+0x68/0x1b0 regmap_read+0x50/0x78 regmap_read_debugfs+0x120/0x338 Fixes: 1acbdeb92c87 ("spi/fsl-dspi: Convert to use regmap and add big-endian support") Co-developed-by: Xulin Sun Signed-off-by: Xulin Sun Signed-off-by: Larisa Grigore Signed-off-by: James Clark Link: https://patch.msgid.link/20250522-james-nxp-spi-v2-1-bea884630cfb@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1d45e0170cf0012205d8e6f4181986d6008dcf83 Author: Greg Kroah-Hartman Date: Thu May 22 12:47:31 2025 +0200 spi: use container_of_cont() for to_spi_device() [ Upstream commit 1007ae0d464ceb55a3740634790521d3543aaab9 ] Some places in the spi core pass in a const pointer to a device and the default container_of() casts that away, which is not a good idea. Preserve the proper const attribute by using container_of_const() for to_spi_device() instead, which is what it was designed for. Note, this removes the NULL check for a device pointer in the call, but no one was ever checking for that return value, and a device pointer should never be NULL overall anyway, so this should be a safe change. Cc: Mark Brown Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2025052230-fidgeting-stooge-66f5@gregkh Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 92f077ff52f2895c33c0e2802983fae7a28acf31 Author: Mark Pearson Date: Mon May 19 20:50:18 2025 -0400 platform/x86: think-lmi: Fix attribute name usage for non-compliant items [ Upstream commit 8508427a6e21c1ef01ae4c9f4e2675fc99deb949 ] A few, quite rare, WMI attributes have names that are not compatible with filenames, e.g. "Intel VT for Directed I/O (VT-d)". For these cases the '/' gets replaced with '\' for display, but doesn't get switched again when doing the WMI access. Fix this by keeping the original attribute name and using that for sending commands to the BIOS Fixes: a40cd7ef22fb ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms") Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20250520005027.3840705-1-mpearson-lenovo@squebb.ca Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5c54a557bde18c0ee0e6adb135230b81b7e2c883 Author: Namjae Jeon Date: Thu May 8 16:46:11 2025 +0900 ksmbd: fix stream write failure [ Upstream commit 1f4bbedd4e5a69b01cde2cc21d01151ab2d0884f ] If there is no stream data in file, v_len is zero. So, If position(*pos) is zero, stream write will fail due to stream write position validation check. This patch reorganize stream write position validation. Fixes: 0ca6df4f40cf ("ksmbd: prevent out-of-bounds stream writes by validating *pos") Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 544ff7fb1972778acbe0a11a0548305c7384f854 Author: Jernej Skrabec Date: Sun Apr 13 15:58:48 2025 +0200 Revert "arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection" [ Upstream commit 573f99c7585f597630f14596550c79e73ffaeef4 ] This reverts commit 531fdbeedeb89bd32018a35c6e137765c9cc9e97. Hardware that uses I2C wasn't designed with high speeds in mind, so communication with PMIC via RSB can intermittently fail. Go back to I2C as higher speed and efficiency isn't worth the trouble. Fixes: 531fdbeedeb8 ("arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection") Link: https://github.com/LibreELEC/LibreELEC.tv/issues/7731 Signed-off-by: Jernej Skrabec Link: https://patch.msgid.link/20250413135848.67283-1-jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 111a892a235d50b02b7149cc2d655187a91207d8 Author: Chris Lu Date: Tue Apr 22 09:21:56 2025 +0800 Bluetooth: btmtksdio: Do close if SDIO card removed without close commit 0b6d58bc6ea85e57de25c828444928e4a0aa79cb upstream. To prevent Bluetooth SDIO card from be physically removed suddenly, driver needs to ensure btmtksdio_close is called before btmtksdio_remove to disable interrupts and txrx workqueue. Fixes: 6ac4233afb9a ("Bluetooth: btmtksdio: Prevent enabling interrupts after IRQ handler removal") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 3e0dc2b4f678c17585ad1371fe3b626b7203c3f1 Author: Chris Lu Date: Tue Apr 22 09:21:55 2025 +0800 Bluetooth: btmtksdio: Check function enabled before doing close commit 07e90048e356a29079fbc011cfc2e1fa1d1c5ac9 upstream. Check BTMTKSDIO_FUNC_ENABLED flag before doing close to prevent btmtksdio_close been called twice. Fixes: 6ac4233afb9a ("Bluetooth: btmtksdio: Prevent enabling interrupts after IRQ handler removal") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit fedd2a1443600c8a91c2c75940ad1527bae1e649 Author: Ryusuke Konishi Date: Sat May 3 14:33:14 2025 +0900 nilfs2: fix deadlock warnings caused by lock dependency in init_nilfs() commit fb881cd7604536b17a1927fb0533f9a6982ffcc5 upstream. After commit c0e473a0d226 ("block: fix race between set_blocksize and read paths") was merged, set_blocksize() called by sb_set_blocksize() now locks the inode of the backing device file. As a result of this change, syzbot started reporting deadlock warnings due to a circular dependency involving the semaphore "ns_sem" of the nilfs object, the inode lock of the backing device file, and the locks that this inode lock is transitively dependent on. This is caused by a new lock dependency added by the above change, since init_nilfs() calls sb_set_blocksize() in the lock section of "ns_sem". However, these warnings are false positives because init_nilfs() is called in the early stage of the mount operation and the filesystem has not yet started. The reason why "ns_sem" is locked in init_nilfs() was to avoid a race condition in nilfs_fill_super() caused by sharing a nilfs object among multiple filesystem instances (super block structures) in the early implementation. However, nilfs objects and super block structures have long ago become one-to-one, and there is no longer any need to use the semaphore there. So, fix this issue by removing the use of the semaphore "ns_sem" in init_nilfs(). Link: https://lkml.kernel.org/r/20250503053327.12294-1-konishi.ryusuke@gmail.com Fixes: c0e473a0d226 ("block: fix race between set_blocksize and read paths") Signed-off-by: Ryusuke Konishi Reported-by: syzbot+00f7f5b884b117ee6773@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=00f7f5b884b117ee6773 Tested-by: syzbot+00f7f5b884b117ee6773@syzkaller.appspotmail.com Reported-by: syzbot+f30591e72bfc24d4715b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f30591e72bfc24d4715b Tested-by: syzbot+f30591e72bfc24d4715b@syzkaller.appspotmail.com> Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 483ac74183e1e85c7d263f3be5a5c55a029b32e8 Author: Kees Cook Date: Thu May 15 14:42:16 2025 -0700 mm: vmalloc: only zero-init on vrealloc shrink commit 70d1eb031a68cbde4eed8099674be21778441c94 upstream. The common case is to grow reallocations, and since init_on_alloc will have already zeroed the whole allocation, we only need to zero when shrinking the allocation. Link: https://lkml.kernel.org/r/20250515214217.619685-2-kees@kernel.org Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Signed-off-by: Kees Cook Tested-by: Pawan Gupta Cc: Danilo Krummrich Cc: Eduard Zingerman Cc: "Erhard F." Cc: Shung-Hsi Yu Cc: "Uladzislau Rezki (Sony)" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 94efb0d6569029ab2a554309dafaba6b95e97869 Author: Kees Cook Date: Thu May 15 14:42:15 2025 -0700 mm: vmalloc: actually use the in-place vrealloc region commit f7a35a3c36d1e36059c5654737d9bee3454f01a3 upstream. Patch series "mm: vmalloc: Actually use the in-place vrealloc region". This fixes a performance regression[1] with vrealloc()[1]. The refactoring to not build a new vmalloc region only actually worked when shrinking. Actually return the resized area when it grows. Ugh. Link: https://lkml.kernel.org/r/20250515214217.619685-1-kees@kernel.org Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Signed-off-by: Kees Cook Reported-by: Shung-Hsi Yu Closes: https://lore.kernel.org/all/20250515-bpf-verifier-slowdown-vwo2meju4cgp2su5ckj@6gi6ssxbnfqg [1] Tested-by: Eduard Zingerman Tested-by: Pawan Gupta Tested-by: Shung-Hsi Yu Reviewed-by: "Uladzislau Rezki (Sony)" Reviewed-by: Danilo Krummrich Cc: "Erhard F." Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9f9517f15686652036909400d954cd236365d8b8 Author: Ignacio Moreno Gonzalez Date: Wed May 7 15:28:06 2025 +0200 mm: mmap: map MAP_STACK to VM_NOHUGEPAGE only if THP is enabled commit 7190b3c8bd2b0cde483bd440cf91ba1c518b4261 upstream. commit c4608d1bf7c6 ("mm: mmap: map MAP_STACK to VM_NOHUGEPAGE") maps the mmap option MAP_STACK to VM_NOHUGEPAGE. This is also done if CONFIG_TRANSPARENT_HUGEPAGE is not defined. But in that case, the VM_NOHUGEPAGE does not make sense. I discovered this issue when trying to use the tool CRIU to checkpoint and restore a container. Our running kernel is compiled without CONFIG_TRANSPARENT_HUGEPAGE. CRIU parses the output of /proc//smaps and saves the "nh" flag. When trying to restore the container, CRIU fails to restore the "nh" mappings, since madvise() MADV_NOHUGEPAGE always returns an error because CONFIG_TRANSPARENT_HUGEPAGE is not defined. Link: https://lkml.kernel.org/r/20250507-map-map_stack-to-vm_nohugepage-only-if-thp-is-enabled-v5-1-c6c38cfefd6e@kuka.com Fixes: c4608d1bf7c6 ("mm: mmap: map MAP_STACK to VM_NOHUGEPAGE") Signed-off-by: Ignacio Moreno Gonzalez Acked-by: David Hildenbrand Reviewed-by: Lorenzo Stoakes Reviewed-by: Yang Shi Reviewed-by: Liam R. Howlett Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9da33ce1142b5bfbcdc18bbde9494f2c2bb4ee5e Author: Tianyang Zhang Date: Wed Apr 16 16:24:05 2025 +0800 mm/page_alloc.c: avoid infinite retries caused by cpuset race commit e05741fb10c38d70bbd7ec12b23c197b6355d519 upstream. __alloc_pages_slowpath has no change detection for ac->nodemask in the part of retry path, while cpuset can modify it in parallel. For some processes that set mempolicy as MPOL_BIND, this results ac->nodemask changes, and then the should_reclaim_retry will judge based on the latest nodemask and jump to retry, while the get_page_from_freelist only traverses the zonelist from ac->preferred_zoneref, which selected by a expired nodemask and may cause infinite retries in some cases cpu 64: __alloc_pages_slowpath { /* ..... */ retry: /* ac->nodemask = 0x1, ac->preferred->zone->nid = 1 */ if (alloc_flags & ALLOC_KSWAPD) wake_all_kswapds(order, gfp_mask, ac); /* cpu 1: cpuset_write_resmask update_nodemask update_nodemasks_hier update_tasks_nodemask mpol_rebind_task mpol_rebind_policy mpol_rebind_nodemask // mempolicy->nodes has been modified, // which ac->nodemask point to */ /* ac->nodemask = 0x3, ac->preferred->zone->nid = 1 */ if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags, did_some_progress > 0, &no_progress_loops)) goto retry; } Simultaneously starting multiple cpuset01 from LTP can quickly reproduce this issue on a multi node server when the maximum memory pressure is reached and the swap is enabled Link: https://lkml.kernel.org/r/20250416082405.20988-1-zhangtianyang@loongson.cn Fixes: c33d6c06f60f ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Signed-off-by: Tianyang Zhang Reviewed-by: Suren Baghdasaryan Reviewed-by: Vlastimil Babka Cc: Michal Hocko Cc: Brendan Jackman Cc: Johannes Weiner Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 314bf771cb87ceef3fe580b4af980127b8ecea09 Author: Breno Leitao Date: Fri May 23 10:21:06 2025 -0700 memcg: always call cond_resched() after fn() commit 06717a7b6c86514dbd6ab322e8083ffaa4db5712 upstream. I am seeing soft lockup on certain machine types when a cgroup OOMs. This is happening because killing the process in certain machine might be very slow, which causes the soft lockup and RCU stalls. This happens usually when the cgroup has MANY processes and memory.oom.group is set. Example I am seeing in real production: [462012.244552] Memory cgroup out of memory: Killed process 3370438 (crosvm) .... .... [462037.318059] Memory cgroup out of memory: Killed process 4171372 (adb) .... [462037.348314] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [stat_manager-ag:1618982] .... Quick look at why this is so slow, it seems to be related to serial flush for certain machine types. For all the crashes I saw, the target CPU was at console_flush_all(). In the case above, there are thousands of processes in the cgroup, and it is soft locking up before it reaches the 1024 limit in the code (which would call the cond_resched()). So, cond_resched() in 1024 blocks is not sufficient. Remove the counter-based conditional rescheduling logic and call cond_resched() unconditionally after each task iteration, after fn() is called. This avoids the lockup independently of how slow fn() is. Link: https://lkml.kernel.org/r/20250523-memcg_fix-v1-1-ad3eafb60477@debian.org Fixes: ade81479c7dd ("memcg: fix soft lockup in the OOM process") Signed-off-by: Breno Leitao Suggested-by: Rik van Riel Acked-by: Shakeel Butt Cc: Michael van der Westhuizen Cc: Usama Arif Cc: Pavel Begunkov Cc: Chen Ridong Cc: Greg Kroah-Hartman Cc: Johannes Weiner Cc: Michal Hocko Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9b8263cae64a6e51ec643cfcec7042d55f3af348 Author: Matthew Wilcox (Oracle) Date: Wed May 14 18:06:02 2025 +0100 highmem: add folio_test_partial_kmap() commit 97dfbbd135cb5e4426f37ca53a8fa87eaaa4e376 upstream. In commit c749d9b7ebbc ("iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP"), Hugh correctly noted that if KMAP_LOCAL_FORCE_MAP is enabled, we must limit ourselves to PAGE_SIZE bytes per call to kmap_local(). The same problem exists in memcpy_from_folio(), memcpy_to_folio(), folio_zero_tail(), folio_fill_tail() and memcpy_from_file_folio(), so add folio_test_partial_kmap() to do this more succinctly. Link: https://lkml.kernel.org/r/20250514170607.3000994-2-willy@infradead.org Fixes: 00cdf76012ab ("mm: add memcpy_from_file_folio()") Signed-off-by: Matthew Wilcox (Oracle) Cc: Al Viro Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb9a1019a63fe30ed769f2cf4e864c492c3f361d Author: Vicki Pfau Date: Tue May 13 15:59:48 2025 -0700 Input: xpad - add more controllers commit f0d17942ea3edec191f1c0fc0d2cd7feca8de2f0 upstream. Adds support for a revision of the Turtle Beach Recon Wired Controller, the Turtle Beach Stealth Ultra, and the PowerA Wired Controller. Signed-off-by: Vicki Pfau Link: https://lore.kernel.org/r/20250513225950.2719387-1-vi@endrift.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7c220f89add8e7d6db63c9c4d9566917f8175a0b Author: Mario Limonciello Date: Thu May 22 09:13:28 2025 -0500 Revert "drm/amd: Keep display off while going into S4" commit 7e7cb7a13c81073d38a10fa7b450d23712281ec4 upstream. commit 68bfdc8dc0a1a ("drm/amd: Keep display off while going into S4") attempted to keep displays off during the S4 sequence by not resuming display IP. This however leads to hangs because DRM clients such as the console can try to access registers and cause a hang. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4155 Fixes: 68bfdc8dc0a1a ("drm/amd: Keep display off while going into S4") Reviewed-by: Alex Deucher Link: https://lore.kernel.org/r/20250522141328.115095-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit e485502c37b097b0bd773baa7e2741bf7bd2909a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b4f801e8cfcc12e206ef5be3cc9cf85b75aeb8dd Author: Wang Zhaolong Date: Fri May 16 17:12:56 2025 +0800 smb: client: Reset all search buffer pointers when releasing buffer commit e48f9d849bfdec276eebf782a84fd4dfbe1c14c0 upstream. Multiple pointers in struct cifs_search_info (ntwrk_buf_start, srch_entries_start, and last_entry) point to the same allocated buffer. However, when freeing this buffer, only ntwrk_buf_start was set to NULL, while the other pointers remained pointing to freed memory. This is defensive programming to prevent potential issues with stale pointers. While the active UAF vulnerability is fixed by the previous patch, this change ensures consistent pointer state and more robust error handling. Signed-off-by: Wang Zhaolong Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 56b06539b67823dc263656453a79310d00d2e295 Author: Gabor Juhos Date: Fri May 9 15:48:52 2025 +0200 arm64: dts: marvell: uDPU: define pinctrl state for alarm LEDs commit b04f0d89e880bc2cca6a5c73cf287082c91878da upstream. The two alarm LEDs of on the uDPU board are stopped working since commit 78efa53e715e ("leds: Init leds class earlier"). The LEDs are driven by the GPIO{15,16} pins of the North Bridge GPIO controller. These pins are part of the 'spi_quad' pin group for which the 'spi' function is selected via the default pinctrl state of the 'spi' node. This is wrong however, since in order to allow controlling the LEDs, the pins should use the 'gpio' function. Before the commit mentined above, the 'spi' function is selected first by the pinctrl core before probing the spi driver, but then it gets overridden to 'gpio' implicitly via the devm_gpiod_get_index_optional() call from the 'leds-gpio' driver. After the commit, the LED subsystem gets initialized before the SPI subsystem, so the function of the pin group remains 'spi' which in turn prevents controlling of the LEDs. Despite the change of the initialization order, the root cause is that the pinctrl state definition is wrong since its initial commit 0d45062cfc89 ("arm64: dts: marvell: Add device tree for uDPU board"), To fix the problem, override the function in the 'spi_quad_pins' node to 'gpio' and move the pinctrl state definition from the 'spi' node into the 'leds' node. Cc: stable@vger.kernel.org # needs adjustment for < 6.1 Fixes: 0d45062cfc89 ("arm64: dts: marvell: Add device tree for uDPU board") Signed-off-by: Gabor Juhos Signed-off-by: Imre Kaloz Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 9bea368648ac46f8593a780760362e40291d22a9 Author: Wang Zhaolong Date: Fri May 16 17:12:55 2025 +0800 smb: client: Fix use-after-free in cifs_fill_dirent commit a7a8fe56e932a36f43e031b398aef92341bf5ea0 upstream. There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------------------------------------- cifs_readdir /* file->private_data == NULL */ initiate_cifs_search cifsFile = kzalloc(sizeof(struct cifsFileInfo), GFP_KERNEL); smb2_query_dir_first ->query_dir_first() SMB2_query_directory SMB2_query_directory_init cifs_send_recv smb2_parse_query_directory srch_inf->ntwrk_buf_start = (char *)rsp; srch_inf->srch_entries_start = (char *)rsp + ... srch_inf->last_entry = (char *)rsp + ... srch_inf->smallBuf = true; find_cifs_entry /* if (cfile->srch_inf.ntwrk_buf_start) */ cifs_small_buf_release(cfile->srch_inf // free cifs_readdir ->iterate_shared() /* file->private_data != NULL */ find_cifs_entry /* in while (...) loop */ smb2_query_dir_next ->query_dir_next() SMB2_query_directory SMB2_query_directory_init cifs_send_recv compound_send_recv smb_send_rqst __smb_send_rqst rc = -ERESTARTSYS; /* if (fatal_signal_pending()) */ goto out; return rc /* if (cfile->srch_inf.last_entry) */ cifs_save_resume_key() cifs_fill_dirent // UAF /* if (rc) */ return -ENOENT; Fix this by ensuring the return code is checked before using pointers from the srch_inf. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220131 [1] Fixes: a364bc0b37f1 ("[CIFS] fix saving of resume key before CIFSFindNext") Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Wang Zhaolong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit dc9bdfb9b02868aca92aa6546c5113bcc9aeea8d Author: feijuan.li Date: Wed May 14 14:35:11 2025 +0800 drm/edid: fixed the bug that hdr metadata was not reset commit 6692dbc15e5ed40a3aa037aced65d7b8826c58cd upstream. When DP connected to a device with HDR capability, the hdr structure was filled.Then connected to another sink device without hdr capability, but the hdr info still exist. Fixes: e85959d6cbe0 ("drm: Parse HDR metadata info from EDID") Cc: # v5.3+ Signed-off-by: "feijuan.li" Reviewed-by: Jani Nikula Link: https://lore.kernel.org/r/20250514063511.4151780-1-feijuan.li@samsung.com Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 56081f5d14c6729fd7d843a0a1075aeca614ca65 Author: Zhang Rui Date: Mon May 19 15:09:01 2025 +0800 thermal: intel: x86_pkg_temp_thermal: Fix bogus trip temperature commit cf948c8e274e8b406e846cdf6cc48fe47f98cf57 upstream. The tj_max value obtained from the Intel TCC library are in Celsius, whereas the thermal subsystem operates in milli-Celsius. This discrepancy leads to incorrect trip temperature calculations. Fix bogus trip temperature by converting tj_max to milli-Celsius Unit. Fixes: 8ef0ca4a177d ("Merge back other thermal control material for 6.3.") Signed-off-by: Zhang Rui Reported-by: zhang ning Closes: https://lore.kernel.org/all/TY2PR01MB3786EF0FE24353026293F5ACCD97A@TY2PR01MB3786.jpnprd01.prod.outlook.com/ Tested-by: zhang ning Cc: 6.3+ # 6.3+ Link: https://patch.msgid.link/20250519070901.1031233-1-rui.zhang@intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8594a123cfa23d708582dc6fb36da34479ef8a5b Author: Vladimir Moskovkin Date: Wed May 14 12:12:55 2025 +0000 platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store() commit 4e89a4077490f52cde652d17e32519b666abf3a6 upstream. If the 'buf' array received from the user contains an empty string, the 'length' variable will be zero. Accessing the 'buf' array element with index 'length - 1' will result in a buffer overflow. Add a check for an empty string. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Moskovkin Link: https://lore.kernel.org/r/39973642a4f24295b4a8fad9109c5b08@kaspersky.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit e78908caf17cbddbceeac35bb54b1ada9610c4e6 Author: Dan Carpenter Date: Thu May 8 09:29:23 2025 +0300 pmdomain: core: Fix error checking in genpd_dev_pm_attach_by_id() commit 0f5757667ec0aaf2456c3b76fcf0c6c3ea3591fe upstream. The error checking for of_count_phandle_with_args() does not handle negative error codes correctly. The problem is that "index" is a u32 so in the condition "if (index >= num_domains)" negative error codes stored in "num_domains" are type promoted to very high positive values and "index" is always going to be valid. Test for negative error codes first and then test if "index" is valid. Fixes: 3ccf3f0cd197 ("PM / Domains: Enable genpd_dev_pm_attach_by_id|name() for single PM domain") Signed-off-by: Dan Carpenter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/aBxPQ8AI8N5v-7rL@stanley.mountain Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0ae82a7abff8f92f96233f63aaf62ded78095fb8 Author: Geert Uytterhoeven Date: Mon Apr 28 13:47:52 2025 +0200 pmdomain: renesas: rcar: Remove obsolete nullify checks commit 13a6d4265665201a795a2ff5a3e6e4d183fc9c33 upstream. All nullify users and helpers were removed, but the R-Car SYSC drivers still checked for nullified domains. Remove the obsolete checks. Fixes: c8d87704444a8ac7 ("pmdomain: renesas: rcar-sysc: Remove rcar_sysc_nullify() helper") Signed-off-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/107f2bf9f13b29f0f623d2959a5347ec151fb089.1745840768.git.geert+renesas@glider.be Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a6ddbf9ae7884bf484abefb95d01fcb470baf2a0 Author: Ronak Doshi Date: Thu May 15 19:04:56 2025 +0000 vmxnet3: update MTU after device quiesce commit 43f0999af011fba646e015f0bb08b6c3002a0170 upstream. Currently, when device mtu is updated, vmxnet3 updates netdev mtu, quiesces the device and then reactivates it for the ESXi to know about the new mtu. So, technically the OS stack can start using the new mtu before ESXi knows about the new mtu. This can lead to issues for TSO packets which use mss as per the new mtu configured. This patch fixes this issue by moving the mtu write after device quiesce. Cc: stable@vger.kernel.org Fixes: d1a890fa37f2 ("net: VMware virtual Ethernet NIC driver: vmxnet3") Signed-off-by: Ronak Doshi Acked-by: Guolin Yang Changes v1-> v2: Moved MTU write after destroy of rx rings Link: https://patch.msgid.link/20250515190457.8597-1-ronak.doshi@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ba689e089369d6821e776b1bc4d25e39450ad506 Author: Jakob Unterwurzacher Date: Thu May 15 09:29:19 2025 +0200 net: dsa: microchip: linearize skb for tail-tagging switches commit ba54bce747fa9e07896c1abd9b48545f7b4b31d2 upstream. The pointer arithmentic for accessing the tail tag only works for linear skbs. For nonlinear skbs, it reads uninitialized memory inside the skb headroom, essentially randomizing the tag. I have observed it gets set to 6 most of the time. Example where ksz9477_rcv thinks that the packet from port 1 comes from port 6 (which does not exist for the ksz9896 that's in use), dropping the packet. Debug prints added by me (not included in this patch): [ 256.645337] ksz9477_rcv:323 tag0=6 [ 256.645349] skb len=47 headroom=78 headlen=0 tailroom=0 mac=(64,14) mac_len=14 net=(78,0) trans=78 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0x0 start=0 offset=0 ip_summed=0 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x00f8 pkttype=1 iif=3 priority=0x0 mark=0x0 alloc_cpu=0 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 256.645377] dev name=end1 feat=0x0002e10200114bb3 [ 256.645386] skb headroom: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 256.645395] skb headroom: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 256.645403] skb headroom: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 256.645411] skb headroom: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 256.645420] skb headroom: 00000040: ff ff ff ff ff ff 00 1c 19 f2 e2 db 08 06 [ 256.645428] skb frag: 00000000: 00 01 08 00 06 04 00 01 00 1c 19 f2 e2 db 0a 02 [ 256.645436] skb frag: 00000010: 00 83 00 00 00 00 00 00 0a 02 a0 2f 00 00 00 00 [ 256.645444] skb frag: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 [ 256.645452] ksz_common_rcv:92 dsa_conduit_find_user returned NULL Call skb_linearize before trying to access the tag. This patch fixes ksz9477_rcv which is used by the ksz9896 I have at hand, and also applies the same fix to ksz8795_rcv which seems to have the same problem. Signed-off-by: Jakob Unterwurzacher CC: stable@vger.kernel.org Fixes: 016e43a26bab ("net: dsa: ksz: Add KSZ8795 tag code") Fixes: 8b8010fb7876 ("dsa: add support for Microchip KSZ tail tagging") Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250515072920.2313014-1-jakob.unterwurzacher@cherry.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 352fbde14177d608a54120b6ff559ce5b3cf6238 Author: Axel Forsman Date: Tue May 20 13:43:31 2025 +0200 can: kvaser_pciefd: Fix echo_skb race commit 8256e0ca601051933e9395746817f3801fa9a6bf upstream. The functions kvaser_pciefd_start_xmit() and kvaser_pciefd_handle_ack_packet() raced to stop/wake TX queues and get/put echo skbs, as kvaser_pciefd_can->echo_lock was only ever taken when transmitting and KCAN_TX_NR_PACKETS_CURRENT gets decremented prior to handling of ACKs. E.g., this caused the following error: can_put_echo_skb: BUG! echo_skb 5 is occupied! Instead, use the synchronization helpers in netdev_queues.h. As those piggyback on BQL barriers, start updating in-flight packets and bytes counts as well. Cc: stable@vger.kernel.org Signed-off-by: Axel Forsman Tested-by: Jimmy Assarsson Reviewed-by: Jimmy Assarsson Link: https://patch.msgid.link/20250520114332.8961-3-axfo@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8654c8a0528d0497861bbb0e6b0ad39e315ddfa1 Author: Axel Forsman Date: Tue May 20 13:43:32 2025 +0200 can: kvaser_pciefd: Continue parsing DMA buf after dropped RX commit 6d820b81c4dc4a4023e45c3cd6707a07dd838649 upstream. Going bus-off on a channel doing RX could result in dropped packets. As netif_running() gets cleared before the channel abort procedure, the handling of any last RDATA packets would see netif_rx() return non-zero to signal a dropped packet. kvaser_pciefd_read_buffer() dealt with this "error" by breaking out of processing the remaining DMA RX buffer. Only return an error from kvaser_pciefd_read_buffer() due to packet corruption, otherwise handle it internally. Cc: stable@vger.kernel.org Signed-off-by: Axel Forsman Tested-by: Jimmy Assarsson Reviewed-by: Jimmy Assarsson Link: https://patch.msgid.link/20250520114332.8961-4-axfo@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 80702f002b136396fcd7957ec635afb010435687 Author: Ilia Gavrilov Date: Thu May 15 12:20:15 2025 +0000 llc: fix data loss when reading from a socket in llc_ui_recvmsg() commit 239af1970bcb039a1551d2c438d113df0010c149 upstream. For SOCK_STREAM sockets, if user buffer size (len) is less than skb size (skb->len), the remaining data from skb will be lost after calling kfree_skb(). To fix this, move the statement for partial reading above skb deletion. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) Fixes: 30a584d944fb ("[LLX]: SOCK_DGRAM interface fixes") Cc: stable@vger.kernel.org Signed-off-by: Ilia Gavrilov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e22325b98245836aeea3b66c659273dff983ec1 Author: Ed Burcher Date: Mon May 19 23:49:07 2025 +0100 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14ASP10 commit 8d70503068510e6080c2c649cccb154f16de26c9 upstream. Lenovo Yoga Pro 7 (gen 10) with Realtek ALC3306 and combined CS35L56 amplifiers need quirk ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN to enable bass Signed-off-by: Ed Burcher Cc: Link: https://patch.msgid.link/20250519224907.31265-2-git@edburcher.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bf85e49aaf3a3c5775ea87369ea5f159c2148db4 Author: Takashi Iwai Date: Fri May 16 10:08:16 2025 +0200 ALSA: pcm: Fix race of buffer access at PCM OSS layer commit 93a81ca0657758b607c3f4ba889ae806be9beb73 upstream. The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com Cc: Link: https://patch.msgid.link/20250516080817.20068-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 799d48c95f9b6ea0b2542616c125347903c33801 Author: Peter Ujfalusi Date: Fri May 9 11:59:51 2025 +0300 ASoC: SOF: ipc4-pcm: Delay reporting is only supported for playback direction commit 98db16f314b3a0d6e5acd94708ea69751436467f upstream. The firmware does not provide any information for capture streams via the shared pipeline registers. To avoid reporting invalid delay value for capture streams to user space we need to disable it. Fixes: af74dbd0dbcf ("ASoC: SOF: ipc4-pcm: allocate time info for pcm delay feature") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20250509085951.15696-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 20e3fa3b7df9d9d58ca1be8b01da989e952437ac Author: Kai Vehmanen Date: Fri May 9 11:53:18 2025 +0300 ASoc: SOF: topology: connect DAI to a single DAI link commit 6052f05254b4fe7b16bbd8224779af52fba98b71 upstream. The partial matching of DAI widget to link names, can cause problems if one of the widget names is a substring of another. E.g. with names "Foo1" and Foo10", it's not possible to correctly link up "Foo1". Modify the logic so that if multiple DAI links match the widget stream name, prioritize a full match if one is found. Fixes: fe88788779fc ("ASoC: SOF: topology: Use partial match for connecting DAI link and DAI widget") Link: https://github.com/thesofproject/linux/issues/5308 Signed-off-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Reviewed-by: Ranjani Sridharan Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20250509085318.13936-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6a62b917fb55bd7eece93b4e4917e429afb247fa Author: Peter Ujfalusi Date: Fri May 9 11:13:08 2025 +0300 ASoC: SOF: Intel: hda-bus: Use PIO mode on ACE2+ platforms commit 4e7010826e96702d7fad13dbe85de4e94052f833 upstream. Keep using the PIO mode for commands on ACE2+ platforms, similarly how the legacy stack is configured. Fixes: 05cf17f1bf6d ("ASoC: SOF: Intel: hda-bus: Use PIO mode for Lunar Lake") Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250509081308.13784-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 964d355832700c239f58dedf6a1cdaeffc71f911 Author: Peter Ujfalusi Date: Fri May 9 11:56:33 2025 +0300 ASoC: SOF: ipc4-control: Use SOF_CTRL_CMD_BINARY as numid for bytes_ext commit 4d14b1069e9e672dbe1adab52594076da6f4a62d upstream. The header.numid is set to scontrol->comp_id in bytes_ext_get and it is ignored during bytes_ext_put. The use of comp_id is not quite great as it is kernel internal identification number. Set the header.numid to SOF_CTRL_CMD_BINARY during get and validate the numid during put to provide consistent and compatible identification number as IPC3. For IPC4 existing tooling also ignored the numid but with the use of SOF_CTRL_CMD_BINARY the different handling of the blobs can be dropped, providing better user experience. Reported-by: Seppo Ingalsuo Closes: https://github.com/thesofproject/linux/issues/5282 Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20250509085633.14930-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 63567ecd99a24495208dc860d50fb17440043006 Author: Oliver Hartkopp Date: Mon May 19 14:50:27 2025 +0200 can: bcm: add missing rcu read protection for procfs content commit dac5e6249159ac255dad9781793dbe5908ac9ddb upstream. When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF). As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection. Fixes: f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly synchronize_rcu()") Reported-by: Anderson Nascimento Suggested-by: Anderson Nascimento Tested-by: Anderson Nascimento Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20250519125027.11900-2-socketcan@hartkopp.net Cc: stable@vger.kernel.org # >= 5.4 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit cc55dd28c20a6611e30596019b3b2f636819a4c0 Author: Oliver Hartkopp Date: Mon May 19 14:50:26 2025 +0200 can: bcm: add locking for bcm_op runtime updates commit c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7 upstream. The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: Anderson Nascimento Tested-by: Anderson Nascimento Reviewed-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20250519125027.11900-1-socketcan@hartkopp.net Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit adb05149a90558029b1ecd9ba1cbb46c7635e4be Author: Carlos Sanchez Date: Tue May 20 12:23:05 2025 +0200 can: slcan: allow reception of short error messages commit ef0841e4cb08754be6cb42bf97739fce5d086e5f upstream. Allows slcan to receive short messages (typically errors) from the serial interface. When error support was added to slcan protocol in b32ff4668544e1333b694fcc7812b2d7397b4d6a ("can: slcan: extend the protocol with error info") the minimum valid message size changed from 5 (minimum standard can frame tIII0) to 3 ("e1a" is a valid protocol message, it is one of the examples given in the comments for slcan_bump_err() ), but the check for minimum message length prodicating all decoding was not adjusted. This makes short error messages discarded and error frames not being generated. This patch changes the minimum length to the new minimum (3 characters, excluding terminator, is now a valid message). Signed-off-by: Carlos Sanchez Fixes: b32ff4668544 ("can: slcan: extend the protocol with error info") Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250520102305.1097494-1-carlossanchez@geotab.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5300e487487d7a2e3e1e6e9d8f03ed9452e4019e Author: Dominik Grzegorzek Date: Sun May 18 19:45:31 2025 +0200 padata: do not leak refcount in reorder_work commit d6ebcde6d4ecf34f8495fb30516645db3aea8993 upstream. A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 Fixes: dd7d37ccf6b1 ("padata: avoid UAF for reorder_work") Cc: Signed-off-by: Dominik Grzegorzek Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 2f45a8d64fb4ed4830a4b3273834ecd6ca504896 Author: Ivan Pravdin Date: Sun May 18 18:41:02 2025 -0400 crypto: algif_hash - fix double free in hash_accept commit b2df03ed4052e97126267e8c13ad4204ea6ba9b6 upstream. If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error. Fixes: fe869cdb89c9 ("crypto: algif_hash - User-space interface for hash operations") Cc: Signed-off-by: Ivan Pravdin Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit bcb1c946c761d9a6f23b56003cfef3c5aef28875 Author: André Draszik Date: Wed Mar 26 12:08:00 2025 +0000 clk: s2mps11: initialise clk_hw_onecell_data::num before accessing ::hws[] in probe() commit 3e14c7207a975eefcda1929b2134a9f4119dde45 upstream. With UBSAN enabled, we're getting the following trace: UBSAN: array-index-out-of-bounds in .../drivers/clk/clk-s2mps11.c:186:3 index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') This is because commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of that struct with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialised with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialisation because the number of elements is zero. This occurs in s2mps11_clk_probe() due to ::num being assigned after ::hws access. Move the assignment to satisfy the requirement of assign-before-access. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Signed-off-by: André Draszik Link: https://lore.kernel.org/r/20250326-s2mps11-ubsan-v1-1-fcc6fce5c8a9@linaro.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 4a7261089d1aa4038f21716d2456b2a39354b1f6 Author: Geetha sowjanya Date: Wed May 21 11:38:34 2025 +0530 octeontx2-af: Fix APR entry mapping based on APR_LMT_CFG [ Upstream commit a6ae7129819ad20788e610261246e71736543b8b ] The current implementation maps the APR table using a fixed size, which can lead to incorrect mapping when the number of PFs and VFs varies. This patch corrects the mapping by calculating the APR table size dynamically based on the values configured in the APR_LMT_CFG register, ensuring accurate representation of APR entries in debugfs. Fixes: 0daa55d033b0 ("octeontx2-af: cn10k: debugfs for dumping LMTST map table"). Signed-off-by: Geetha sowjanya Link: https://patch.msgid.link/20250521060834.19780-3-gakula@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 92b04bac366f06bb3e0b762842aa5ab5a80ac81a Author: Subbaraya Sundeep Date: Wed May 21 11:38:33 2025 +0530 octeontx2-af: Set LMT_ENA bit for APR table entries [ Upstream commit 0eefa27b493306928d88af6368193b134c98fd64 ] This patch enables the LMT line for a PF/VF by setting the LMT_ENA bit in the APR_LMT_MAP_ENTRY_S structure. Additionally, it simplifies the logic for calculating the LMTST table index by consistently using the maximum number of hw supported VFs (i.e., 256). Fixes: 873a1e3d207a ("octeontx2-af: cn10k: Setting up lmtst map table"). Signed-off-by: Subbaraya Sundeep Signed-off-by: Geetha sowjanya Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250521060834.19780-2-gakula@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 689a205cd968a1572ab561b0c4c2d50a10e9d3b0 Author: Wang Liang Date: Tue May 20 18:14:04 2025 +0800 net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done [ Upstream commit e279024617134c94fd3e37470156534d5f2b3472 ] Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt. Reported-by: syzbot+55c12726619ff85ce1f6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=55c12726619ff85ce1f6 Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Signed-off-by: Wang Liang Link: https://patch.msgid.link/20250520101404.1341730-1-wangliang74@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 41678d7222850a053d18f116e11f96b060df69d2 Author: Suman Ghosh Date: Thu Feb 13 11:01:37 2025 +0530 octeontx2-pf: Add AF_XDP non-zero copy support [ Upstream commit b4164de5041b51cda3438e75bce668e2556057c3 ] Set xdp rx ring memory type as MEM_TYPE_PAGE_POOL for af-xdp to work. This is needed since xdp_return_frame internally will use page pools. Fixes: 06059a1a9a4a ("octeontx2-pf: Add XDP support to netdev PF") Signed-off-by: Suman Ghosh Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 49b21795b8e5654a7df3d910a12e1060da4c04cf Author: Cong Wang Date: Sun May 18 15:20:37 2025 -0700 sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() [ Upstream commit 3f981138109f63232a5fb7165938d4c945cc1b9d ] When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free. This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek. Fixes: 12d0ad3be9c3 ("net/sched/sch_hfsc.c: handle corner cases where head may change invalidating calculated deadline") Reported-by: Mingi Cho Signed-off-by: Cong Wang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250518222038.58538-2-xiyou.wangcong@gmail.com Reviewed-by: Jamal Hadi Salim Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0a2422f97651cb9517fe6f5f1ab62c97db5c12df Author: Eric Dumazet Date: Tue May 20 12:40:30 2025 +0000 idpf: fix idpf_vport_splitq_napi_poll() [ Upstream commit 407e0efdf8baf1672876d5948b75049860a93e59 ] idpf_vport_splitq_napi_poll() can incorrectly return @budget after napi_complete_done() has been called. This violates NAPI rules, because after napi_complete_done(), current thread lost napi ownership. Move the test against POLL_MODE before the napi_complete_done(). Fixes: c2d548cad150 ("idpf: add TX splitq napi poll support") Reported-by: Peter Newman Closes: https://lore.kernel.org/netdev/20250520121908.1805732-1-edumazet@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Joshua Hay Cc: Alan Brady Cc: Madhu Chittim Cc: Phani Burra Cc: Pavan Kumar Linga Link: https://patch.msgid.link/20250520124030.1983936-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 873ebaf3c111337277bc69722128492887cc0ba6 Author: Pavel Begunkov Date: Sat May 17 13:27:37 2025 +0100 io_uring: fix overflow resched cqe reordering [ Upstream commit a7d755ed9ce9738af3db602eb29d32774a180bc7 ] Leaving the CQ critical section in the middle of a overflow flushing can cause cqe reordering since the cache cq pointers are reset and any new cqe emitters that might get called in between are not going to be forced into io_cqe_cache_refill(). Fixes: eac2ca2d682f9 ("io_uring: check if we need to reschedule during overflow flush") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/90ba817f1a458f091f355f407de1c911d2b93bbf.1747483784.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 845ef0462ac7064f9df5fbe2982a6418bd5644a9 Author: Thangaraj Samynathan Date: Fri May 16 09:27:19 2025 +0530 net: lan743x: Restore SGMII CTRL register on resume [ Upstream commit 293e38ff4e4c2ba53f3fd47d8a4a9f0f0414a7a6 ] SGMII_CTRL register, which specifies the active interface, was not properly restored when resuming from suspend. This led to incorrect interface selection after resume particularly in scenarios involving the FPGA. To fix this: - Move the SGMII_CTRL setup out of the probe function. - Initialize the register in the hardware initialization helper function, which is called during both device initialization and resume. This ensures the interface configuration is consistently restored after suspend/resume cycles. Fixes: a46d9d37c4f4f ("net: lan743x: Add support for SGMII interface") Signed-off-by: Thangaraj Samynathan Link: https://patch.msgid.link/20250516035719.117960-1-thangaraj.s@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e4fd8e76dd7e0f505d12191b166397ab402ee82 Author: Paul Kocialkowski Date: Mon May 19 18:49:36 2025 +0200 net: dwmac-sun8i: Use parsed internal PHY address instead of 1 [ Upstream commit 47653e4243f2b0a26372e481ca098936b51ec3a8 ] While the MDIO address of the internal PHY on Allwinner sun8i chips is generally 1, of_mdio_parse_addr is used to cleanly parse the address from the device-tree instead of hardcoding it. A commit reworking the code ditched the parsed value and hardcoded the value 1 instead, which didn't really break anything but is more fragile and not future-proof. Restore the initial behavior using the parsed address returned from the helper. Fixes: 634db83b8265 ("net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs") Signed-off-by: Paul Kocialkowski Reviewed-by: Andrew Lunn Acked-by: Corentin LABBE Tested-by: Corentin LABBE Link: https://patch.msgid.link/20250519164936.4172658-1-paulk@sys-base.io Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e79182c82a11a2f55b3975c7c64403c4b87212d Author: Dmitry Baryshkov Date: Tue May 13 21:38:58 2025 +0300 pinctrl: qcom: switch to devm_register_sys_off_handler() [ Upstream commit 41e452e6933d14146381ea25cff5e4d1ac2abea1 ] Error-handling paths in msm_pinctrl_probe() don't call a function required to unroll restart handler registration, unregister_restart_handler(). Instead of adding calls to this function, switch the msm pinctrl code into using devm_register_sys_off_handler(). Fixes: cf1fc1876289 ("pinctrl: qcom: use restart_notifier mechanism for ps_hold") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/20250513-pinctrl-msm-fix-v2-2-249999af0fc1@oss.qualcomm.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cd7f022296972daf35b750c3fa71a6bc9ebc0abf Author: Christoph Hellwig Date: Tue May 20 15:54:20 2025 +0200 loop: don't require ->write_iter for writable files in loop_configure [ Upstream commit 355341e4359b2d5edf0ed5e117f7e9e7a0a5dac0 ] Block devices can be opened read-write even if they can't be written to for historic reasons. Remove the check requiring file->f_op->write_iter when the block devices was opened in loop_configure. The call to loop_check_backing_file just below ensures the ->write_iter is present for backing files opened for writing, which is the only check that is actually needed. Fixes: f5c84eff634b ("loop: Add sanity check for read/write_iter") Reported-by: Christian Hesse Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250520135420.1177312-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f6f5e9c8cb680c3cb9771fd9fa114319cbc4f514 Author: Pavan Kumar Linga Date: Fri Apr 11 09:00:35 2025 -0700 idpf: fix null-ptr-deref in idpf_features_check [ Upstream commit 2dabe349f7882ff1407a784d54d8541909329088 ] idpf_features_check is used to validate the TX packet. skb header length is compared with the hardware supported value received from the device control plane. The value is stored in the adapter structure and to access it, vport pointer is used. During reset all the vports are released and the vport pointer that the netdev private structure points to is NULL. To avoid null-ptr-deref, store the max header length value in netdev private structure. This also helps to cache the value and avoid accessing adapter pointer in hot path. BUG: kernel NULL pointer dereference, address: 0000000000000068 ... RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ... Fixes: a251eee62133 ("idpf: add SRIOV support and other ndo_ops") Reviewed-by: Madhu Chititm Signed-off-by: Pavan Kumar Linga Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8c3b8ace9ce4a3d2aef5ca452e34791930184b95 Author: Dave Ertman Date: Mon Apr 28 15:33:39 2025 -0400 ice: Fix LACP bonds without SRIOV environment [ Upstream commit 6c778f1b839b63525b30046c9d1899424a62be0a ] If an aggregate has the following conditions: - The SRIOV LAG DDP package has been enabled - The bond is in 802.3ad LACP mode - The bond is disqualified from supporting SRIOV VF LAG - Both interfaces were added simultaneously to the bond (same command) Then there is a chance that the two interfaces will be assigned different LACP Aggregator ID's. This will cause a failure of the LACP control over the bond. To fix this, we can detect if the primary interface for the bond (as defined by the driver) is not in switchdev mode, and exit the setup flow if so. Reproduction steps: %> ip link add bond0 type bond mode 802.3ad miimon 100 %> ip link set bond0 up %> ifenslave bond0 eth0 eth1 %> cat /proc/net/bonding/bond0 | grep Agg Check for Aggregator IDs that differ. Fixes: ec5a6c5f79ed ("ice: process events created by lag netdev event handler") Reviewed-by: Aleksandr Loktionov Signed-off-by: Dave Ertman Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7191b69eae0f5b2b7f3432c86ebc5f7ef1fd5787 Author: Jacob Keller Date: Thu Apr 10 11:13:52 2025 -0700 ice: fix vf->num_mac count with port representors [ Upstream commit bbd95160a03dbfcd01a541f25c27ddb730dfbbd5 ] The ice_vc_repr_add_mac() function indicates that it does not store the MAC address filters in the firmware. However, it still increments vf->num_mac. This is incorrect, as vf->num_mac should represent the number of MAC filters currently programmed to firmware. Indeed, we only perform this increment if the requested filter is a unicast address that doesn't match the existing vf->hw_lan_addr. In addition, ice_vc_repr_del_mac() does not decrement the vf->num_mac counter. This results in the counter becoming out of sync with the actual count. As it turns out, vf->num_mac is currently only used in legacy made without port representors. The single place where the value is checked is for enforcing a filter limit on untrusted VFs. Upcoming patches to support VF Live Migration will use this value when determining the size of the TLV for MAC address filters. Fix the representor mode function to stop incrementing the counter incorrectly. Fixes: ac19e03ef780 ("ice: allow process VF opcodes in different ways") Signed-off-by: Jacob Keller Reviewed-by: Michal Swiatkowski Reviewed-by: Simon Horman Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 233a227a317b0bb99cf19aed3e530401774014b2 Author: Ido Schimmel Date: Thu May 15 11:48:48 2025 +0300 bridge: netfilter: Fix forwarding of fragmented packets [ Upstream commit 91b6dbced0ef1d680afdd69b14fc83d50ebafaf3 ] When netfilter defrag hooks are loaded (due to the presence of conntrack rules, for example), fragmented packets entering the bridge will be defragged by the bridge's pre-routing hook (br_nf_pre_routing() -> ipv4_conntrack_defrag()). Later on, in the bridge's post-routing hook, the defragged packet will be fragmented again. If the size of the largest fragment is larger than what the kernel has determined as the destination MTU (using ip_skb_dst_mtu()), the defragged packet will be dropped. Before commit ac6627a28dbf ("net: ipv4: Consolidate ipv4_mtu and ip_dst_mtu_maybe_forward"), ip_skb_dst_mtu() would return dst_mtu() as the destination MTU. Assuming the dst entry attached to the packet is the bridge's fake rtable one, this would simply be the bridge's MTU (see fake_mtu()). However, after above mentioned commit, ip_skb_dst_mtu() ends up returning the route's MTU stored in the dst entry's metrics. Ideally, in case the dst entry is the bridge's fake rtable one, this should be the bridge's MTU as the bridge takes care of updating this metric when its MTU changes (see br_change_mtu()). Unfortunately, the last operation is a no-op given the metrics attached to the fake rtable entry are marked as read-only. Therefore, ip_skb_dst_mtu() ends up returning 1500 (the initial MTU value) and defragged packets are dropped during fragmentation when dealing with large fragments and high MTU (e.g., 9k). Fix by moving the fake rtable entry's metrics to be per-bridge (in a similar fashion to the fake rtable entry itself) and marking them as writable, thereby allowing MTU changes to be reflected. Fixes: 62fa8a846d7d ("net: Implement read-only protection and COW'ing of metrics.") Fixes: 33eb9873a283 ("bridge: initialize fake_rtable metrics") Reported-by: Venkat Venkatsubra Closes: https://lore.kernel.org/netdev/PH0PR10MB4504888284FF4CBA648197D0ACB82@PH0PR10MB4504.namprd10.prod.outlook.com/ Tested-by: Venkat Venkatsubra Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250515084848.727706-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b7d3e782027ac3b6fec56159e8e348042000aef Author: Sagi Maimon Date: Wed May 14 10:35:41 2025 +0300 ptp: ocp: Limit signal/freq counts in summary output functions [ Upstream commit c9e455581e2ba87ee38c126e8dc49a424b9df0cf ] The debugfs summary output could access uninitialized elements in the freq_in[] and signal_out[] arrays, causing NULL pointer dereferences and triggering a kernel Oops (page_fault_oops). This patch adds u8 fields (nr_freq_in, nr_signal_out) to track the number of initialized elements, with a maximum of 4 per array. The summary output functions are updated to respect these limits, preventing out-of-bounds access and ensuring safe array handling. Widen the label variables because the change confuses GCC about max length of the strings. Fixes: ef61f5528fca ("ptp: ocp: add Adva timecard support") Signed-off-by: Sagi Maimon Reviewed-by: Simon Horman Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250514073541.35817-1-maimon.sagi@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a1f9a709a6164633af8cb494bc497fe5f578654 Author: En-Wei Wu Date: Thu May 8 22:15:20 2025 +0800 Bluetooth: btusb: use skb_pull to avoid unsafe access in QCA dump handling [ Upstream commit 4bcb0c7dc25446b99fc7a8fa2a143d69f3314162 ] Use skb_pull() and skb_pull_data() to safely parse QCA dump packets. This avoids direct pointer math on skb->data, which could lead to invalid access if the packet is shorter than expected. Fixes: 20981ce2d5a5 ("Bluetooth: btusb: Add WCN6855 devcoredump support") Signed-off-by: En-Wei Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1e8b7e96f71fe0fe01fb1a26383f36d62a315d45 Author: Luiz Augusto von Dentz Date: Wed May 7 15:00:30 2025 -0400 Bluetooth: L2CAP: Fix not checking l2cap_chan security level [ Upstream commit 7af8479d9eb4319b4ba7b47a8c4d2c55af1c31e1 ] l2cap_check_enc_key_size shall check the security level of the l2cap_chan rather than the hci_conn since for incoming connection request that may be different as hci_conn may already been encrypted using a different security level. Fixes: 522e9ed157e3 ("Bluetooth: l2cap: Check encryption key size on incoming connection") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ca51db23166767a8445deb8331c9b8d5205d9287 Author: Adrian Hunter Date: Thu May 8 16:44:52 2025 +0300 perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq [ Upstream commit 99bcd91fabada0dbb1d5f0de44532d8008db93c6 ] Currently, using PEBS-via-PT with a sample frequency instead of a sample period, causes a segfault. For example: BUG: kernel NULL pointer dereference, address: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50 That happens because intel_pmu_pebs_event_update_no_drain() assumes all the pebs_enabled bits represent counter indexes, which is not always the case. In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes. The behaviour of PEBS-via-PT with sample frequency is questionable because although a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not adjusted anyway. Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing the mask of counter bits instead of 'size'. Note, prior to the Fixes commit, 'size' would be limited to the maximum counter index, so the issue was not hit. Fixes: 722e42e45c2f1 ("perf/x86: Support counter mask") Signed-off-by: Adrian Hunter Signed-off-by: Ingo Molnar Reviewed-by: Kan Liang Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: Ian Rogers Cc: linux-perf-users@vger.kernel.org Link: https://lore.kernel.org/r/20250508134452.73960-1-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit 1c1fb885e5885bdba13e0e65597aa5e4aaa75967 Author: Andrew Bresticker Date: Wed May 14 10:13:20 2025 -0700 irqchip/riscv-imsic: Start local sync timer on correct CPU [ Upstream commit 08fb624802d8786253994d8ebdbbcdaa186f04f5 ] When starting the local sync timer to synchronize the state of a remote CPU it should be added on the CPU to be synchronized, not the initiating CPU. This results in interrupt delivery being delayed until the timer eventually runs (due to another mask/unmask/migrate operation) on the target CPU. Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector") Signed-off-by: Andrew Bresticker Signed-off-by: Thomas Gleixner Reviewed-by: Anup Patel Link: https://lore.kernel.org/all/20250514171320.3494917-1-abrestic@rivosinc.com Signed-off-by: Sasha Levin commit 2b49e68360eb6a1c03dc1642a51f7d9f6784c034 Author: Tavian Barnes Date: Wed May 14 09:37:49 2025 -0400 ASoC: SOF: Intel: hda: Fix UAF when reloading module [ Upstream commit 7dd7f39fce0022b386ef1ea5ffef92ecc7dfc6af ] hda_generic_machine_select() appends -idisp to the tplg filename by allocating a new string with devm_kasprintf(), then stores the string right back into the global variable snd_soc_acpi_intel_hda_machines. When the module is unloaded, this memory is freed, resulting in a global variable pointing to freed memory. Reloading the module then triggers a use-after-free: BUG: KFENCE: use-after-free read in string+0x48/0xe0 Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it by copying the match array with devm_kmemdup_array() before we modify it. Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") Suggested-by: Peter Ujfalusi Acked-by: Peter Ujfalusi Signed-off-by: Tavian Barnes Link: https://patch.msgid.link/570b15570b274520a0d9052f4e0f064a29c950ef.1747229716.git.tavianator@tavianator.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4a39fbffad5cd3379d517fc034b9cc43771a7854 Author: Raag Jadav Date: Wed Feb 12 11:55:05 2025 +0530 devres: Introduce devm_kmemdup_array() [ Upstream commit a103b833ac3806b816bc993cba77d0b17cf801f1 ] Introduce '_array' variant of devm_kmemdup() which is more robust and consistent with alloc family of helpers. Suggested-by: Andy Shevchenko Signed-off-by: Raag Jadav Reviewed-by: Dmitry Torokhov Reviewed-by: Linus Walleij Signed-off-by: Andy Shevchenko Stable-dep-of: 7dd7f39fce00 ("ASoC: SOF: Intel: hda: Fix UAF when reloading module") Signed-off-by: Sasha Levin commit 7207effe4743f49eb8b74ceb66e170b70e4746d2 Author: Andy Shevchenko Date: Wed Feb 12 11:55:03 2025 +0530 driver core: Split devres APIs to device/devres.h [ Upstream commit a21cad9312767d26b5257ce0662699bb202cdda1 ] device.h is a huge header which is hard to follow and easy to miss something. Improve that by splitting devres APIs to device/devres.h. In particular this helps to speedup the build of the code that includes device.h solely for a devres APIs. While at it, cast the error pointers to __iomem using IOMEM_ERR_PTR() and fix sparse warnings. Signed-off-by: Raag Jadav Acked-by: Arnd Bergmann Reviewed-by: Greg Kroah-Hartman Signed-off-by: Andy Shevchenko Stable-dep-of: 7dd7f39fce00 ("ASoC: SOF: Intel: hda: Fix UAF when reloading module") Signed-off-by: Sasha Levin commit ae344b9f842d99c95a1df7006b901cf3ab8bc8bf Author: Stefan Wahren Date: Thu Apr 24 13:48:29 2025 +0200 dmaengine: fsl-edma: Fix return code for unhandled interrupts [ Upstream commit 5e27af0514e2249a9ccc9a762abd3b74e03a1f90 ] For fsl,imx93-edma4 two DMA channels share the same interrupt. So in case fsl_edma3_tx_handler is called for the "wrong" channel, the return code must be IRQ_NONE. This signalize that the interrupt wasn't handled. Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Stefan Wahren Reviewed-by: Joy Zou Link: https://lore.kernel.org/r/20250424114829.9055-1-wahrenst@gmx.net Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d31daa83efbab525ebadb79a8ae26c75e325b547 Author: Dave Jiang Date: Thu May 8 10:05:48 2025 -0700 dmaengine: idxd: Fix ->poll() return value [ Upstream commit ae74cd15ade833adc289279b5c6f12e78f64d4d7 ] The fix to block access from different address space did not return a correct value for ->poll() change. kernel test bot reported that a return value of type __poll_t is expected rather than int. Fix to return POLLNVAL to indicate invalid request. Fixes: 8dfa57aabff6 ("dmaengine: idxd: Fix allowing write() from different address spaces") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505081851.rwD7jVxg-lkp@intel.com/ Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/20250508170548.2747425-1-dave.jiang@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 252f78a9317acfaca9ba2d3154a107e281295bdf Author: Paul Chaignon Date: Wed May 7 13:31:58 2025 +0200 xfrm: Sanitize marks before insert [ Upstream commit 0b91fda3a1f044141e1e615456ff62508c32b202 ] Prior to this patch, the mark is sanitized (applying the state's mask to the state's value) only on inserts when checking if a conflicting XFRM state or policy exists. We discovered in Cilium that this same sanitization does not occur in the hot-path __xfrm_state_lookup. In the hot-path, the sk_buff's mark is simply compared to the state's value: if ((mark & x->mark.m) != x->mark.v) continue; Therefore, users can define unsanitized marks (ex. 0xf42/0xf00) which will never match any packet. This commit updates __xfrm_state_insert and xfrm_policy_insert to store the sanitized marks, thus removing this footgun. This has the side effect of changing the ip output, as the returned mark will have the mask applied to it when printed. Fixes: 3d6acfa7641f ("xfrm: SA lookups with mark") Signed-off-by: Paul Chaignon Signed-off-by: Louis DeLosSantos Co-developed-by: Louis DeLosSantos Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ae5e975a46e268e2ce95094314762449549462ca Author: Andre Przywara Date: Thu May 1 13:06:31 2025 +0100 clk: sunxi-ng: d1: Add missing divider for MMC mod clocks [ Upstream commit 98e6da673cc6dd46ca9a599802bd2c8f83606710 ] The D1/R528/T113 SoCs have a hidden divider of 2 in the MMC mod clocks, just as other recent SoCs. So far we did not describe that, which led to the resulting MMC clock rate to be only half of its intended value. Use a macro that allows to describe a fixed post-divider, to compensate for that divisor. This brings the MMC performance on those SoCs to its expected level, so about 23 MB/s for SD cards, instead of the 11 MB/s measured so far. Fixes: 35b97bb94111 ("clk: sunxi-ng: Add support for the D1 SoC clocks") Reported-by: Kuba Szczodrzyński Signed-off-by: Andre Przywara Link: https://patch.msgid.link/20250501120631.837186-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 090aa8d51ec6c2413e14859edfa81c9def5782ca Author: Matti Lehtimäki Date: Mon May 12 02:40:15 2025 +0300 remoteproc: qcom_wcnss: Fix on platforms without fallback regulators [ Upstream commit 4ca45af0a56d00b86285d6fdd720dca3215059a7 ] Recent change to handle platforms with only single power domain broke pronto-v3 which requires power domains and doesn't have fallback voltage regulators in case power domains are missing. Add a check to verify the number of fallback voltage regulators before using the code which handles single power domain situation. Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Signed-off-by: Matti Lehtimäki Tested-by: Luca Weiss # sdm632-fairphone-fp3 Link: https://lore.kernel.org/r/20250511234026.94735-1-matti.lehtimaki@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 447c8f0c06190b582824144c5264b93e0de3b161 Author: David Hildenbrand Date: Tue Apr 22 16:49:42 2025 +0200 kernel/fork: only call untrack_pfn_clear() on VMAs duplicated for fork() [ Upstream commit e9f180d7cfde23b9f8eebd60272465176373ab2c ] Not intuitive, but vm_area_dup() located in kernel/fork.c is not only used for duplicating VMAs during fork(), but also for duplicating VMAs when splitting VMAs or when mremap()'ing them. VM_PFNMAP mappings can at least get ordinarily mremap()'ed (no change in size) and apparently also shrunk during mremap(), which implies duplicating the VMA in __split_vma() first. In case of ordinary mremap() (no change in size), we first duplicate the VMA in copy_vma_and_data()->copy_vma() to then call untrack_pfn_clear() on the old VMA: we effectively move the VM_PAT reservation. So the untrack_pfn_clear() call on the new VMA duplicating is wrong in that context. Splitting of VMAs seems problematic, because we don't duplicate/adjust the reservation when splitting the VMA. Instead, in memtype_erase() -- called during zapping/munmap -- we shrink a reservation in case only the end address matches: Assume we split a VMA into A and B, both would share a reservation until B is unmapped. So when unmapping B, the reservation would be updated to cover only A. When unmapping A, we would properly remove the now-shrunk reservation. That scenario describes the mremap() shrinking (old_size > new_size), where we split + unmap B, and the untrack_pfn_clear() on the new VMA when is wrong. What if we manage to split a VM_PFNMAP VMA into A and B and unmap A first? It would be broken because we would never free the reservation. Likely, there are ways to trigger such a VMA split outside of mremap(). Affecting other VMA duplication was not intended, vm_area_dup() being used outside of kernel/fork.c was an oversight. So let's fix that for; how to handle VMA splits better should be investigated separately. With a simple reproducer that uses mprotect() to split such a VMA I can trigger x86/PAT: pat_mremap:26448 freeing invalid memtype [mem 0x00000000-0x00000fff] Link: https://lkml.kernel.org/r/20250422144942.2871395-1-david@redhat.com Fixes: dc84bc2aba85 ("x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()") Signed-off-by: David Hildenbrand Reviewed-by: Lorenzo Stoakes Cc: Ingo Molnar Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Rik van Riel Cc: "H. Peter Anvin" Cc: Linus Torvalds Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 7f5dc43b462051fe2c4084f040cad96d94ed67b9 Author: Seongman Lee Date: Sun May 11 18:23:28 2025 +0900 x86/sev: Fix operator precedence in GHCB_MSR_VMPL_REQ_LEVEL macro [ Upstream commit f7387eff4bad33d12719c66c43541c095556ae4e ] The GHCB_MSR_VMPL_REQ_LEVEL macro lacked parentheses around the bitmask expression, causing the shift operation to bind too early. As a result, when requesting VMPL1 (e.g., GHCB_MSR_VMPL_REQ_LEVEL(1)), incorrect values such as 0x000000016 were generated instead of the intended 0x100000016 (the requested VMPL level is specified in GHCBData[39:32]). Fix the precedence issue by grouping the masked value before applying the shift. [ bp: Massage commit message. ] Fixes: 34ff65901735 ("x86/sev: Use kernel provided SVSM Calling Areas") Signed-off-by: Seongman Lee Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250511092329.12680-1-cloudlee1719@gmail.com Signed-off-by: Sasha Levin commit d91576a2321d7c4ccba879bd5135061713261fa3 Author: Vinicius Costa Gomes Date: Mon Apr 21 10:03:37 2025 -0700 dmaengine: idxd: Fix allowing write() from different address spaces [ Upstream commit 8dfa57aabff625bf445548257f7711ef294cd30e ] Check if the process submitting the descriptor belongs to the same address space as the one that opened the file, reject otherwise. Fixes: 6827738dc684 ("dmaengine: idxd: add a write() method for applications to submit work") Signed-off-by: Vinicius Costa Gomes Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/20250421170337.3008875-1-dave.jiang@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b1a687eb15bcf5cec5213a43b1236710a79526bf Author: Tobias Brunner Date: Tue Apr 15 13:13:18 2025 +0200 xfrm: Fix UDP GRO handling for some corner cases [ Upstream commit e3fd0577768584ece824c8b661c40fb3d912812a ] This fixes an issue that's caused if there is a mismatch between the data offset in the GRO header and the length fields in the regular sk_buff due to the pskb_pull()/skb_push() calls. That's because the UDP GRO layer stripped off the UDP header via skb_gro_pull() already while the UDP header was explicitly not pulled/pushed in this function. For example, an IKE packet that triggered this had len=data_len=1268 and the data_offset in the GRO header was 28 (IPv4 + UDP). So pskb_pull() was called with an offset of 28-8=20, which reduced len to 1248 and via pskb_may_pull() and __pskb_pull_tail() it also set data_len to 1248. As the ESP offload module was not loaded, the function bailed out and called skb_push(), which restored len to 1268, however, data_len remained at 1248. So while skb_headlen() was 0 before, it was now 20. The latter caused a difference of 8 instead of 28 (or 0 if pskb_pull()/skb_push() was called with the complete GRO data_offset) in gro_try_pull_from_frag0() that triggered a call to gro_pull_from_frag0() that corrupted the packet. This change uses a more GRO-like approach seen in other GRO receivers via skb_gro_header() to just read the actual data we are interested in and does not try to "restore" the UDP header at this point to call the existing function. If the offload module is not loaded, it immediately bails out, otherwise, it only does a quick check to see if the packet is an IKE or keepalive packet instead of calling the existing function. Fixes: 172bf009c18d ("xfrm: Support GRO for IPv4 ESP in UDP encapsulation") Fixes: 221ddb723d90 ("xfrm: Support GRO for IPv6 ESP in UDP encapsulation") Signed-off-by: Tobias Brunner Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 9cbca30102028f9ad3d2098f935c4368f581fd07 Author: Sabrina Dubroca Date: Wed Apr 9 15:59:57 2025 +0200 espintcp: remove encap socket caching to avoid reference leak [ Upstream commit 028363685bd0b7a19b4a820f82dd905b1dc83999 ] The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 28756f22de48d25256ed89234b66b9037a3f0157 Author: Sabrina Dubroca Date: Wed Apr 9 15:59:56 2025 +0200 espintcp: fix skb leaks [ Upstream commit 63c1f19a3be3169e51a5812d22a6d0c879414076 ] A few error paths are missing a kfree_skb. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 153bc79b5d02c167385afb05ab0e35d4baea3c96 Author: Charles Keepax Date: Wed Apr 9 13:22:39 2025 +0100 soundwire: bus: Fix race on the creation of the IRQ domain [ Upstream commit fd15594ba7d559d9da741504c322b9f57c4981e5 ] The SoundWire IRQ domain needs to be created before any slaves are added to the bus, such that the domain is always available when needed. Move the call to sdw_irq_create() before the calls to sdw_acpi_find_slaves() and sdw_of_find_slaves(). Fixes: 12a95123bfe1 ("soundwire: bus: Allow SoundWire peripherals to register IRQ handlers") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20250409122239.1396489-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8cafd7266fa02e0863bacbf872fe635c0b9725eb Author: Al Viro Date: Sun Apr 27 15:41:51 2025 -0400 __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock [ Upstream commit 250cf3693060a5f803c5f1ddc082bb06b16112a9 ] ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with. Reviewed-by: Christian Brauner Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit a0c50c9f9c912507ef8111ba5d5e595b7e699d61 Author: Austin Zheng Date: Thu Apr 17 10:24:29 2025 -0400 drm/amd/display: Call FP Protect Before Mode Programming/Mode Support [ Upstream commit eba692ca3abca258b3214a6e4126afefad1822f0 ] [Why] Memory allocation occurs within dml21_validate() for adding phantom planes. May cause kernel to be tainted due to usage of FP Start. [How] Move FP start from dml21_validate to before mode programming/mode support. Calculations requiring floating point are all done within mode programming or mode support. Reviewed-by: Alvin Lee Signed-off-by: Austin Zheng Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit fe3250f10819b411808ab9ae1d824c5fc9b59170) Signed-off-by: Sasha Levin commit 211f58920645951259520cd41be6fa00fa9ebbda Author: Jason Andryuk Date: Tue May 6 16:44:56 2025 -0400 xenbus: Allow PVH dom0 a non-local xenstore [ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ] Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a xenstore stubdom, dom0 can be handled as a regular XS_HVM following the late init path. Ideally we'd drop the use of xen_initial_domain() and just check for the event channel instead. However, ARM has a xen,enhanced no-xenstore mode, where the event channel and PFN would both be 0. Retain the xen_initial_domain() check, and use that for an additional check when the event channel is 0. Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off chance that high bits are set for the 32bit event channel. Signed-off-by: Jason Andryuk Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437 Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com> Signed-off-by: Sasha Levin commit 5a8d073d87da4ad1496b35adaee5719e94665d81 Author: Paweł Anikiel Date: Thu Apr 10 11:54:20 2025 +0000 x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST or Rust >= 1.88 [ Upstream commit 5595c31c370957aabe739ac3996aedba8267603f ] Calling core::fmt::write() from rust code while FineIBT is enabled results in a kernel panic: [ 4614.199779] kernel BUG at arch/x86/kernel/cet.c:132! [ 4614.205343] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 4614.211781] CPU: 2 UID: 0 PID: 6057 Comm: dmabuf_dump Tainted: G U O 6.12.17-android16-0-g6ab38c534a43 #1 9da040f27673ec3945e23b998a0f8bd64c846599 [ 4614.227832] Tainted: [U]=USER, [O]=OOT_MODULE [ 4614.241247] RIP: 0010:do_kernel_cp_fault+0xea/0xf0 ... [ 4614.398144] RIP: 0010:_RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x0/0x20 [ 4614.407792] Code: 48 f7 df 48 0f 48 f9 48 89 f2 89 c6 5d e9 18 fd ff ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 41 81 ea 14 61 af 2c 74 03 0f 0b 90 <66> 0f 1f 00 55 48 89 e5 48 89 f2 48 8b 3f be 01 00 00 00 5d e9 e7 [ 4614.428775] RSP: 0018:ffffb95acfa4ba68 EFLAGS: 00010246 [ 4614.434609] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000 [ 4614.442587] RDX: 0000000000000007 RSI: ffffb95acfa4ba70 RDI: ffffb95acfa4bc88 [ 4614.450557] RBP: ffffb95acfa4bae0 R08: ffff0a00ffffff05 R09: 0000000000000070 [ 4614.458527] R10: 0000000000000000 R11: ffffffffab67eaf0 R12: ffffb95acfa4bcc8 [ 4614.466493] R13: ffffffffac5d50f0 R14: 0000000000000000 R15: 0000000000000000 [ 4614.474473] ? __cfi__RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x10/0x10 [ 4614.484118] ? _RNvNtCs3o2tGsuHyou_4core3fmt5write+0x1d2/0x250 This happens because core::fmt::write() calls core::fmt::rt::Argument::fmt(), which currently has CFI disabled: library/core/src/fmt/rt.rs: 171 // FIXME: Transmuting formatter in new and indirectly branching to/calling 172 // it here is an explicit CFI violation. 173 #[allow(inline_no_sanitize)] 174 #[no_sanitize(cfi, kcfi)] 175 #[inline] 176 pub(super) unsafe fn fmt(&self, f: &mut Formatter<'_>) -> Result { This causes a Control Protection exception, because FineIBT has sealed off the original function's endbr64. This makes rust currently incompatible with FineIBT. Add a Kconfig dependency that prevents FineIBT from getting turned on by default if rust is enabled. [ Rust 1.88.0 (scheduled for 2025-06-26) should have this fixed [1], and thus we relaxed the condition with Rust >= 1.88. When `objtool` lands checking for this with e.g. [2], the plan is to ideally run that in upstream Rust's CI to prevent regressions early [3], since we do not control `core`'s source code. Alice tested the Rust PR backported to an older compiler. Peter would like that Rust provides a stable `core` which can be pulled into the kernel: "Relying on that much out of tree code is 'unfortunate'". - Miguel ] Signed-off-by: Paweł Anikiel Reviewed-by: Alice Ryhl Acked-by: Peter Zijlstra Link: https://github.com/rust-lang/rust/pull/139632 [1] Link: https://lore.kernel.org/rust-for-linux/20250410154556.GB9003@noisy.programming.kicks-ass.net/ [2] Link: https://github.com/rust-lang/rust/pull/139632#issuecomment-2801950873 [3] Link: https://lore.kernel.org/r/20250410115420.366349-1-panikiel@google.com Link: https://lore.kernel.org/r/att0-CANiq72kjDM0cKALVy4POEzhfdT4nO7tqz0Pm7xM+3=_0+L1t=A@mail.gmail.com [ Reduced splat. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit b8581b4e4d96ededfe28778bb27ca585fc092b59 Author: Johannes Berg Date: Tue May 6 21:42:59 2025 +0200 wifi: iwlwifi: add support for Killer on MTL [ Upstream commit ebedf8b7f05b9c886d68d63025db8d1b12343157 ] For now, we need another entry for these devices, this will be changed completely for 6.16. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219926 Link: https://patch.msgid.link/20250506214258.2efbdc9e9a82.I31915ec252bd1c74bd53b89a0e214e42a74b6f2e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1645fc1849ef0e116e8a03d8a11e980d6b356290 Author: Johannes Thumshirn Date: Tue May 6 13:27:30 2025 +0200 block: only update request sector if needed [ Upstream commit db492e24f9b05547ba12b4783f09c9d943cf42fe ] In case of a ZONE APPEND write, regardless of native ZONE APPEND or the emulation layer in the zone write plugging code, the sector the data got written to by the device needs to be updated in the bio. At the moment, this is done for every native ZONE APPEND write and every request that is flagged with 'BIO_ZONE_WRITE_PLUGGING'. But thus superfluously updates the sector for regular writes to a zoned block device. Check if a bio is a native ZONE APPEND write or if the bio is flagged as 'BIO_EMULATES_ZONE_APPEND', meaning the block layer's zone write plugging code handles the ZONE APPEND and translates it into a regular write and back. Only if one of these two criterion is met, update the sector in the bio upon completion. Signed-off-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/dea089581cb6b777c1cd1500b38ac0b61df4b2d1.1746530748.git.jth@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 511ea82e344e044aad215a4456ab400a70565e54 Author: David Wei Date: Fri May 2 21:30:50 2025 -0700 tools: ynl-gen: validate 0 len strings from kernel [ Upstream commit 4720f9707c783f642332dee3d56dccaefa850e42 ] Strings from the kernel are guaranteed to be null terminated and ynl_attr_validate() checks for this. But it doesn't check if the string has a len of 0, which would cause problems when trying to access data[len - 1]. Fix this by checking that len is positive. Signed-off-by: David Wei Link: https://patch.msgid.link/20250503043050.861238-1-dw@davidwei.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6e9770de024964b1017f99ee94f71967bd6edaeb Author: Qu Wenruo Date: Tue Apr 29 15:17:50 2025 +0930 btrfs: avoid NULL pointer dereference if no valid csum tree [ Upstream commit f95d186255b319c48a365d47b69bd997fecb674e ] [BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification. Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all. This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash. [FIX] Check both extent and csum tree root before doing any tree search. Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 230c94ca3527dafc206666a56cb7823a7edc66a5 Author: Boris Burkov Date: Fri Apr 25 12:47:50 2025 -0700 btrfs: handle empty eb->folios in num_extent_folios() [ Upstream commit d6fe0c69b3aa5c985380b794bdf8e6e9b1811e60 ] num_extent_folios() unconditionally calls folio_order() on eb->folios[0]. If that is NULL this will be a segfault. It is reasonable for it to return 0 as the number of folios in the eb when the first entry is NULL, so do that instead. Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7f7c8c03feba5f2454792fab3bb8bd45bd6883f9 Author: Goldwyn Rodrigues Date: Fri Apr 25 09:25:06 2025 -0400 btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref [ Upstream commit bc7e0975093567f51be8e1bdf4aa5900a3cf0b1e ] btrfs_prelim_ref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to trace_btrfs_prelim_ref_insert(). Note, trace_btrfs_prelim_ref_insert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref. To reproduce: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable Perform some writeback operations. Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0 Signed-off-by: Goldwyn Rodrigues Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 92dff981dddffe6f5f7a4ed53d28623627a3151b Author: Kees Cook Date: Fri Apr 25 23:23:29 2025 -0700 btrfs: compression: adjust cb->compressed_folios allocation type [ Upstream commit 6f9a8ab796c6528d22de3c504c81fce7dde63d8a ] In preparation for making the kmalloc() family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct folio **" but the returned type will be "struct page **". These are the same allocation size (pointer size), but the types don't match. Adjust the allocation type to match the assignment. Reviewed-by: Qu Wenruo Signed-off-by: Kees Cook Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5926bc887da2f044c92ec270bdc73ac9681d99fa Author: Stefan Binding Date: Wed Apr 30 11:31:19 2025 +0100 ASoC: intel/sdw_utils: Add volume limit to cs42l43 speakers [ Upstream commit 02b44a2b2bdcee03cbb92484d31e9ca1b91b2a38 ] The volume control for cs42l43 speakers has a maximum gain of +31.5 dB. However, for many use cases, this can cause distorted audio, depending various factors, such as other signal-processing elements in the chain, for example if the audio passes through a gain control before reaching the codec or the signal path has been tuned for a particular maximum gain in the codec. In the case of systems which use the soc_sdw_cs42l43 driver, audio will likely be distorted in all cases above 0 dB, therefore add a volume limit of 128, which is 0 dB maximum volume inside this driver. Signed-off-by: Stefan Binding Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20250430103134.24579-2-sbinding@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6b1a9a76470971a3a3ac222a1aea75c25309af39 Author: Pali Rohár Date: Mon Dec 30 21:32:39 2024 +0100 cifs: Fix changing times and read-only attr over SMB1 smb_set_file_info() function [ Upstream commit f122121796f91168d0894c2710b8dd71330a34f8 ] Function CIFSSMBSetPathInfo() is not supported by non-NT servers and returns error. Fallback code via open filehandle and CIFSSMBSetFileInfo() does not work neither because CIFS_open() works also only on NT server. Therefore currently the whole smb_set_file_info() function as a SMB1 callback for the ->set_file_info() does not work with older non-NT SMB servers, like Win9x and others. This change implements fallback code in smb_set_file_info() which will works with any server and allows to change time values and also to set or clear read-only attributes. To make existing fallback code via CIFSSMBSetFileInfo() working with also non-NT servers, it is needed to change open function from CIFS_open() (which is NT specific) to cifs_open_file() which works with any server (this is just a open wrapper function which choose the correct open function supported by the server). CIFSSMBSetFileInfo() is working also on non-NT servers, but zero time values are not treated specially. So first it is needed to fill all time values if some of them are missing, via cifs_query_path_info() call. There is another issue, opening file in write-mode (needed for changing attributes) is not possible when the file has read-only attribute set. The only option how to clear read-only attribute is via SMB_COM_SETATTR command. And opening directory is not possible neither and here the SMB_COM_SETATTR command is the only option how to change attributes. And CIFSSMBSetFileInfo() does not honor setting read-only attribute, so for setting is also needed to use SMB_COM_SETATTR command. Existing code in cifs_query_path_info() is already using SMB_COM_GETATTR as a fallback code path (function SMBQueryInformation()), so introduce a new function SMBSetInformation which will implement SMB_COM_SETATTR command. My testing showed that Windows XP SMB1 client is also using SMB_COM_SETATTR command for setting or clearing read-only attribute against non-NT server. So this can prove that this is the correct way how to do it. With this change it is possible set all 4 time values and all attributes, including clearing and setting read-only bit on non-NT SMB servers. Tested against Win98 SMB1 server. This change fixes "touch" command which was failing when called on existing file. And fixes also "chmod +w" and "chmod -w" commands which were also failing (as they are changing read-only attribute). Note that this change depends on following change "cifs: Improve cifs_query_path_info() and cifs_query_file_info()" as it require to query all 4 time attribute values. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0a9920e1ff67d17dd605e5ed9cd4778d42e9051e Author: Pali Rohár Date: Mon Dec 30 20:34:18 2024 +0100 cifs: Fix and improve cifs_query_path_info() and cifs_query_file_info() [ Upstream commit 1041c117a2c33cdffc4f695ac4b469e9124d24d5 ] When CAP_NT_SMBS was not negotiated then do not issue CIFSSMBQPathInfo() and CIFSSMBQFileInfo() commands. CIFSSMBQPathInfo() is not supported by non-NT Win9x SMB server and CIFSSMBQFileInfo() returns from Win9x SMB server bogus data in Attributes field (for example lot of files are marked as reparse points, even Win9x does not support them and read-only bit is not marked for read-only files). Correct information is returned by CIFSFindFirst() or SMBQueryInformation() command. So as a fallback in cifs_query_path_info() function use CIFSFindFirst() with SMB_FIND_FILE_FULL_DIRECTORY_INFO level which is supported by both NT and non-NT servers and as a last option use SMBQueryInformation() as it was before. And in function cifs_query_file_info() immediately returns -EOPNOTSUPP when not communicating with NT server. Client then revalidate inode entry by the cifs_query_path_info() call, which is working fine. So fstat() syscall on already opened file will receive correct information. Note that both fallback functions in non-UNICODE mode expands wildcards. Therefore those fallback functions cannot be used on paths which contain SMB wildcard characters (* ? " > <). CIFSFindFirst() returns all 4 time attributes as opposite of SMBQueryInformation() which returns only one. With this change it is possible to query all 4 times attributes from Win9x server and at the same time, client minimize sending of unsupported commands to server. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ad3e83a6c80335e285b62786097b4dc53dbad170 Author: Jens Axboe Date: Wed Apr 30 07:17:17 2025 -0600 io_uring/fdinfo: annotate racy sq/cq head/tail reads [ Upstream commit f024d3a8ded0d8d2129ae123d7a5305c29ca44ce ] syzbot complains about the cached sq head read, and it's totally right. But we don't need to care, it's just reading fdinfo, and reading the CQ or SQ tail/head entries are known racy in that they are just a view into that very instant and may of course be outdated by the time they are reported. Annotate both the SQ head and CQ tail read with data_race() to avoid this syzbot complaint. Link: https://lore.kernel.org/io-uring/6811f6dc.050a0220.39e3a1.0d0e.GAE@google.com/ Reported-by: syzbot+3e77fd302e99f5af9394@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ec462449f4cf616b0aa2ed119f5f44b5fdfcefab Author: Alistair Francis Date: Wed Apr 23 16:06:21 2025 +1000 nvmet-tcp: don't restore null sk_state_change [ Upstream commit 46d22b47df2741996af277a2838b95f130436c13 ] queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if the TCP connection isn't established when nvmet_tcp_set_queue_sock() is called then queue->state_change isn't set and sock->sk->sk_state_change isn't replaced. As such we don't need to restore sock->sk->sk_state_change if queue->state_change is NULL. This avoids NULL pointer dereferences such as this: [ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 [ 286.498550][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.499137][ C0] ? __pfx_ip_rcv_finish+0x10/0x10 [ 286.499763][ C0] ? lock_release+0x217/0x2c0 [ 286.500327][ C0] ? dl_scaled_delta_exec+0xd1/0x2c0 [ 286.500922][ C0] ? __pfx_ip_rcv+0x10/0x10 [ 286.501480][ C0] __netif_receive_skb_one_core+0x166/0x1b0 [ 286.502173][ C0] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 286.502903][ C0] ? lock_acquire+0x2b2/0x310 [ 286.503487][ C0] ? process_backlog+0x372/0x1350 [ 286.504087][ C0] ? lock_release+0x217/0x2c0 [ 286.504642][ C0] process_backlog+0x3b9/0x1350 [ 286.505214][ C0] ? process_backlog+0x372/0x1350 [ 286.505779][ C0] __napi_poll.constprop.0+0xa6/0x490 [ 286.506363][ C0] net_rx_action+0x92e/0xe10 [ 286.506889][ C0] ? __pfx_net_rx_action+0x10/0x10 [ 286.507437][ C0] ? timerqueue_add+0x1f0/0x320 [ 286.507977][ C0] ? sched_clock_cpu+0x68/0x540 [ 286.508492][ C0] ? lock_acquire+0x2b2/0x310 [ 286.509043][ C0] ? kvm_sched_clock_read+0xd/0x20 [ 286.509607][ C0] ? handle_softirqs+0x1aa/0x7d0 [ 286.510187][ C0] handle_softirqs+0x1f2/0x7d0 [ 286.510754][ C0] ? __pfx_handle_softirqs+0x10/0x10 [ 286.511348][ C0] ? irqtime_account_irq+0x181/0x290 [ 286.511937][ C0] ? __dev_queue_xmit+0x85d/0x3450 [ 286.512510][ C0] do_softirq.part.0+0x89/0xc0 [ 286.513100][ C0] [ 286.513548][ C0] [ 286.513953][ C0] __local_bh_enable_ip+0x112/0x140 [ 286.514522][ C0] ? __dev_queue_xmit+0x85d/0x3450 [ 286.515072][ C0] __dev_queue_xmit+0x872/0x3450 [ 286.515619][ C0] ? nft_do_chain+0xe16/0x15b0 [nf_tables] [ 286.516252][ C0] ? __pfx___dev_queue_xmit+0x10/0x10 [ 286.516817][ C0] ? selinux_ip_postroute+0x43c/0xc50 [ 286.517433][ C0] ? __pfx_selinux_ip_postroute+0x10/0x10 [ 286.518061][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.518606][ C0] ? ip_output+0x164/0x4a0 [ 286.519149][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.519671][ C0] ? ip_finish_output2+0x17d5/0x1fb0 [ 286.520258][ C0] ip_finish_output2+0xb4b/0x1fb0 [ 286.520787][ C0] ? __pfx_ip_finish_output2+0x10/0x10 [ 286.521355][ C0] ? __ip_finish_output+0x15d/0x750 [ 286.521890][ C0] ip_output+0x164/0x4a0 [ 286.522372][ C0] ? __pfx_ip_output+0x10/0x10 [ 286.522872][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.523402][ C0] ? _raw_spin_unlock_irqrestore+0x4c/0x60 [ 286.524031][ C0] ? __pfx_ip_finish_output+0x10/0x10 [ 286.524605][ C0] ? __ip_queue_xmit+0x999/0x2260 [ 286.525200][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.525744][ C0] ? ipv4_dst_check+0x16a/0x2b0 [ 286.526279][ C0] ? lock_release+0x217/0x2c0 [ 286.526793][ C0] __ip_queue_xmit+0x1883/0x2260 [ 286.527324][ C0] ? __skb_clone+0x54c/0x730 [ 286.527827][ C0] __tcp_transmit_skb+0x209b/0x37a0 [ 286.528374][ C0] ? __pfx___tcp_transmit_skb+0x10/0x10 [ 286.528952][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.529472][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.530152][ C0] ? trace_hardirqs_on+0x12/0x120 [ 286.530691][ C0] tcp_write_xmit+0xb81/0x88b0 [ 286.531224][ C0] ? mod_memcg_state+0x4d/0x60 [ 286.531736][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.532253][ C0] __tcp_push_pending_frames+0x90/0x320 [ 286.532826][ C0] tcp_send_fin+0x141/0xb50 [ 286.533352][ C0] ? __pfx_tcp_send_fin+0x10/0x10 [ 286.533908][ C0] ? __local_bh_enable_ip+0xab/0x140 [ 286.534495][ C0] inet_shutdown+0x243/0x320 [ 286.535077][ C0] nvme_tcp_alloc_queue+0xb3b/0x2590 [nvme_tcp] [ 286.535709][ C0] ? do_raw_spin_lock+0x129/0x260 [ 286.536314][ C0] ? __pfx_nvme_tcp_alloc_queue+0x10/0x10 [nvme_tcp] [ 286.536996][ C0] ? do_raw_spin_unlock+0x54/0x1e0 [ 286.537550][ C0] ? _raw_spin_unlock+0x29/0x50 [ 286.538127][ C0] ? do_raw_spin_lock+0x129/0x260 [ 286.538664][ C0] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 286.539249][ C0] ? nvme_tcp_alloc_admin_queue+0xd5/0x340 [nvme_tcp] [ 286.539892][ C0] ? __wake_up+0x40/0x60 [ 286.540392][ C0] nvme_tcp_alloc_admin_queue+0xd5/0x340 [nvme_tcp] [ 286.541047][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.541589][ C0] nvme_tcp_setup_ctrl+0x8b/0x7a0 [nvme_tcp] [ 286.542254][ C0] ? _raw_spin_unlock_irqrestore+0x4c/0x60 [ 286.542887][ C0] ? __pfx_nvme_tcp_setup_ctrl+0x10/0x10 [nvme_tcp] [ 286.543568][ C0] ? trace_hardirqs_on+0x12/0x120 [ 286.544166][ C0] ? _raw_spin_unlock_irqrestore+0x35/0x60 [ 286.544792][ C0] ? nvme_change_ctrl_state+0x196/0x2e0 [nvme_core] [ 286.545477][ C0] nvme_tcp_create_ctrl+0x839/0xb90 [nvme_tcp] [ 286.546126][ C0] nvmf_dev_write+0x3db/0x7e0 [nvme_fabrics] [ 286.546775][ C0] ? rw_verify_area+0x69/0x520 [ 286.547334][ C0] vfs_write+0x218/0xe90 [ 286.547854][ C0] ? do_syscall_64+0x9f/0x190 [ 286.548408][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.549037][ C0] ? syscall_exit_to_user_mode+0x93/0x280 [ 286.549659][ C0] ? __pfx_vfs_write+0x10/0x10 [ 286.550259][ C0] ? do_syscall_64+0x9f/0x190 [ 286.550840][ C0] ? syscall_exit_to_user_mode+0x8e/0x280 [ 286.551516][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.552180][ C0] ? syscall_exit_to_user_mode+0x93/0x280 [ 286.552834][ C0] ? ksys_read+0xf5/0x1c0 [ 286.553386][ C0] ? __pfx_ksys_read+0x10/0x10 [ 286.553964][ C0] ksys_write+0xf5/0x1c0 [ 286.554499][ C0] ? __pfx_ksys_write+0x10/0x10 [ 286.555072][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.555698][ C0] ? syscall_exit_to_user_mode+0x93/0x280 [ 286.556319][ C0] ? do_syscall_64+0x54/0x190 [ 286.556866][ C0] do_syscall_64+0x93/0x190 [ 286.557420][ C0] ? rcu_read_unlock+0x17/0x60 [ 286.557986][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.558526][ C0] ? lock_release+0x217/0x2c0 [ 286.559087][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.559659][ C0] ? count_memcg_events.constprop.0+0x4a/0x60 [ 286.560476][ C0] ? exc_page_fault+0x7a/0x110 [ 286.561064][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.561647][ C0] ? lock_release+0x217/0x2c0 [ 286.562257][ C0] ? do_user_addr_fault+0x171/0xa00 [ 286.562839][ C0] ? do_user_addr_fault+0x4a2/0xa00 [ 286.563453][ C0] ? irqentry_exit_to_user_mode+0x84/0x270 [ 286.564112][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.564677][ C0] ? irqentry_exit_to_user_mode+0x84/0x270 [ 286.565317][ C0] ? trace_hardirqs_on_prepare+0xdb/0x120 [ 286.565922][ C0] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 286.566542][ C0] RIP: 0033:0x7fe3c05e6504 [ 286.567102][ C0] Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d c5 8b 10 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 [ 286.568931][ C0] RSP: 002b:00007fff76444f58 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ 286.569807][ C0] RAX: ffffffffffffffda RBX: 000000003b40d930 RCX: 00007fe3c05e6504 [ 286.570621][ C0] RDX: 00000000000000cf RSI: 000000003b40d930 RDI: 0000000000000003 [ 286.571443][ C0] RBP: 0000000000000003 R08: 00000000000000cf R09: 000000003b40d930 [ 286.572246][ C0] R10: 0000000000000000 R11: 0000000000000202 R12: 000000003b40cd60 [ 286.573069][ C0] R13: 00000000000000cf R14: 00007fe3c07417f8 R15: 00007fe3c073502e [ 286.573886][ C0] Closes: https://lore.kernel.org/linux-nvme/5hdonndzoqa265oq3bj6iarwtfk5dewxxjtbjvn5uqnwclpwt6@a2n6w3taxxex/ Signed-off-by: Alistair Francis Reviewed-by: Sagi Grimberg Tested-by: Shin'ichiro Kawasaki Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 6a09b6bad09a6f0bb499430ae3aa58a4a085ec6e Author: Takashi Iwai Date: Tue Apr 29 20:36:15 2025 +0200 ALSA: usb-audio: Fix duplicated name in MIDI substream names [ Upstream commit 0759e77a6d9bd34a874da73721ce4a7dc6665023 ] The MIDI substream name string is constructed from the combination of the card shortname (which is taken from USB iProduct) and the USB iJack. The problem is that some devices put the product name to the iJack field, too. For example, aplaymidi -l output on the Lanchkey MK 49 are like: % aplaymidi -l Port Client name Port name 44:0 Launchkey MK4 49 Launchkey MK4 49 Launchkey MK4 44:1 Launchkey MK4 49 Launchkey MK4 49 Launchkey MK4 where the actual iJack name can't be seen because it's truncated due to the doubly words. For resolving those situations, this patch compares the iJack string with the card shortname, and drops if both start with the same words. Then the result becomes like: % aplaymidi -l Port Client name Port name 40:0 Launchkey MK4 49 Launchkey MK4 49 MIDI In 40:1 Launchkey MK4 49 Launchkey MK4 49 DAW In A caveat is that there are some pre-defined names for certain devices in the driver code, and this workaround shouldn't be applied to them. Similarly, when the iJack isn't specified, we should skip this check, too. The patch added those checks in addition to the string comparison. Suggested-by: Paul Davis Tested-by: Paul Davis Link: https://lore.kernel.org/CAFa_cKmEDQWcJatbYWi6A58Zg4Ma9_6Nr3k5LhqwyxC-P_kXtw@mail.gmail.com Link: https://patch.msgid.link/20250429183626.20773-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6d196cae4b0b2432f2638eced6f4a8989974dd56 Author: Wentao Guan Date: Thu Apr 24 10:40:10 2025 +0800 nvme-pci: add quirks for WDC Blue SN550 15b7:5009 [ Upstream commit ab35ad950d439ec3409509835d229b3d93d3c7f9 ] Add two quirks for the WDC Blue SN550 (PCI ID 15b7:5009) based on user reports and hardware analysis: - NVME_QUIRK_NO_DEEPEST_PS: liaozw talked to me the problem and solved with nvme_core.default_ps_max_latency_us=0, so add the quirk. I also found some reports in the following link. - NVME_QUIRK_BROKEN_MSI: after get the lspci from Jack Rio. I think that the disk also have NVME_QUIRK_BROKEN_MSI. described in commit d5887dc6b6c0 ("nvme-pci: Add quirk for broken MSIs") as sean said in link which match the MSI 1/32 and MSI-X 17. Log: lspci -nn | grep -i memory 03:00.0 Non-Volatile memory controller [0108]: Sandisk Corp SanDisk Ultra 3D / WD PC SN530, IX SN530, Blue SN550 NVMe SSD (DRAM-less) [15b7:5009] (rev 01) lspci -v -d 15b7:5009 03:00.0 Non-Volatile memory controller: Sandisk Corp SanDisk Ultra 3D / WD PC SN530, IX SN530, Blue SN550 NVMe SSD (DRAM-less) (rev 01) (prog-if 02 [NVM Express]) Subsystem: Sandisk Corp WD Blue SN550 NVMe SSD Flags: bus master, fast devsel, latency 0, IRQ 35, IOMMU group 10 Memory at fe800000 (64-bit, non-prefetchable) [size=16K] Memory at fe804000 (64-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [b0] MSI-X: Enable+ Count=17 Masked- Capabilities: [c0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [150] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [1b8] Latency Tolerance Reporting Capabilities: [300] Secondary PCI Express Capabilities: [900] L1 PM Substates Kernel driver in use: nvme dmesg | grep nvme [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.12.20-amd64-desktop-rolling root=UUID= ro splash quiet nvme_core.default_ps_max_latency_us=0 DEEPIN_GFXMODE= [ 0.059301] Kernel command line: BOOT_IMAGE=/vmlinuz-6.12.20-amd64-desktop-rolling root=UUID= ro splash quiet nvme_core.default_ps_max_latency_us=0 DEEPIN_GFXMODE= [ 0.542430] nvme nvme0: pci function 0000:03:00.0 [ 0.560426] nvme nvme0: allocated 32 MiB host memory buffer. [ 0.562491] nvme nvme0: 16/0/0 default/read/poll queues [ 0.567764] nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 [ 6.388726] EXT4-fs (nvme0n1p7): mounted filesystem ro with ordered data mode. Quota mode: none. [ 6.893421] EXT4-fs (nvme0n1p7): re-mounted r/w. Quota mode: none. [ 7.125419] Adding 16777212k swap on /dev/nvme0n1p8. Priority:-2 extents:1 across:16777212k SS [ 7.157588] EXT4-fs (nvme0n1p6): mounted filesystem r/w with ordered data mode. Quota mode: none. [ 7.165021] EXT4-fs (nvme0n1p9): mounted filesystem r/w with ordered data mode. Quota mode: none. [ 8.036932] nvme nvme0: using unchecked data buffer [ 8.096023] block nvme0n1: No UUID available providing old NGUID Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5887dc6b6c054d0da3cd053afc15b7be1f45ff6 Link: https://lore.kernel.org/all/20240422162822.3539156-1-sean.anderson@linux.dev/ Reported-by: liaozw Closes: https://bbs.deepin.org.cn/post/286300 Reported-by: rugk Closes: https://bugzilla.kernel.org/show_bug.cgi?id=208123 Signed-off-by: Wentao Guan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ff214b079d55ed596b7e820d2a3a5a6116434f19 Author: Wentao Guan Date: Tue Apr 22 20:17:25 2025 +0800 nvme-pci: add quirks for device 126f:1001 [ Upstream commit 5b960f92ac3e5b4d7f60a506a6b6735eead1da01 ] This commit adds NVME_QUIRK_NO_DEEPEST_PS and NVME_QUIRK_BOGUS_NID for device [126f:1001]. It is similar to commit e89086c43f05 ("drivers/nvme: Add quirks for device 126f:2262") Diff is according the dmesg, use NVME_QUIRK_IGNORE_DEV_SUBNQN. dmesg | grep -i nvme0: nvme nvme0: pci function 0000:01:00.0 nvme nvme0: missing or invalid SUBNQN field. nvme nvme0: 12/0/0 default/read/poll queues Link:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e89086c43f0500bc7c4ce225495b73b8ce234c1f Signed-off-by: Wentao Guan Signed-off-by: WangYuli Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 35ec11b38588cfb336127ad45a989f13b88804b0 Author: Takashi Iwai Date: Sun Apr 27 10:10:34 2025 +0200 ALSA: hda/realtek: Add quirk for HP Spectre x360 15-df1xxx [ Upstream commit be0c40da888840fe91b45474cb70779e6cbaf7ca ] HP Spectre x360 15-df1xxx with SSID 13c:863e requires similar workarounds that were applied to another HP Spectre x360 models; it has a mute LED only, no micmute LEDs, and needs the speaker GPIO seup. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220054 Link: https://patch.msgid.link/20250427081035.11567-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8f76431c00b2dab4fbc0b359747a5f7a2f9d126a Author: Takashi Iwai Date: Sun Apr 20 10:56:59 2025 +0200 ASoC: Intel: bytcr_rt5640: Add DMI quirk for Acer Aspire SW3-013 [ Upstream commit a549b927ea3f5e50b1394209b64e6e17e31d4db8 ] Acer Aspire SW3-013 requires the very same quirk as other Acer Aspire model for making it working. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220011 Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250420085716.12095-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 63affdae7ff494a9f685726f23dfafdec12fd241 Author: Charles Keepax Date: Wed Apr 23 10:09:44 2025 +0100 ASoC: cs42l43: Disable headphone clamps during type detection [ Upstream commit 70ad2e6bd180f94be030aef56e59693e36d945f3 ] The headphone clamps cause fairly loud pops during type detect because they sink current from the detection process itself. Disable the clamps whilst the type detect runs, to improve the detection pop performance. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20250423090944.1504538-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4c7a0425fb6209a756f8e63cd2a6f7bf0a1f962a Author: Gašper Nemgar Date: Fri Apr 18 09:07:38 2025 +0200 platform/x86: ideapad-laptop: add support for some new buttons [ Upstream commit 02c6e43397c39edd0c172859bf8c851b46be09a8 ] Add entries to unsupported WMI codes in ideapad_keymap[] and one check for WMI code 0x13d to trigger platform_profile_cycle(). Signed-off-by: Gašper Nemgar Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250418070738.7171-1-gasper.nemgar@gmail.com [ij: joined nested if ()s & major tweaks to changelog] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2418bf5d383fa52b54560f3a91a0a8c2ab0d848f Author: Pavel Nikulin Date: Fri Apr 18 20:06:08 2025 +0600 platform/x86: asus-wmi: Disable OOBE state after resume from hibernation [ Upstream commit 77bdac73754e4c0c564c1ca80fe3d9c93b0e715a ] ASUS firmware resets OOBE state during S4 suspend, so the keyboard blinks during resume from hibernation. This patch disables OOBE state after resume from hibernation. Signed-off-by: Pavel Nikulin Link: https://lore.kernel.org/r/20250418140706.1691-1-pavel@noa-labs.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 00fe4c0e469596e339d084d0d258af03c80fc790 Author: Saranya Gopal Date: Mon Apr 21 09:43:32 2025 +0530 platform/x86/intel: hid: Add Pantherlake support [ Upstream commit 12df9ec3e1955aed6a0c839f2375cd8e5d5150cf ] Add Pantherlake ACPI device ID to the Intel HID driver. While there, clean up the device ID table to remove the ", 0" parts. Suggested-by: Andy Shevchenko Signed-off-by: Saranya Gopal Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250421041332.830136-1-saranya.gopal@intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit aa000a4ee9897762a254bd190ac314366fb7f0f3 Author: Salah Triki Date: Wed Apr 16 20:26:25 2025 +0100 smb: server: smb2pdu: check return value of xa_store() [ Upstream commit af5226abb40cae959f424f7ca614787a1c87ce48 ] xa_store() may fail so check its return value and return error code if error occurred. Signed-off-by: Salah Triki Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c134c62b9e97b2bd789e72d6fa89a37a3ab084fe Author: Martin Blumenstingl Date: Sat Mar 29 20:01:32 2025 +0100 pinctrl: meson: define the pull up/down resistor value as 60 kOhm [ Upstream commit e56088a13708757da68ad035269d69b93ac8c389 ] The public datasheets of the following Amlogic SoCs describe a typical resistor value for the built-in pull up/down resistor: - Meson8/8b/8m2: not documented - GXBB (S905): 60 kOhm - GXL (S905X): 60 kOhm - GXM (S912): 60 kOhm - G12B (S922X): 60 kOhm - SM1 (S905D3): 60 kOhm The public G12B and SM1 datasheets additionally state min and max values: - min value: 50 kOhm for both, pull-up and pull-down - max value for the pull-up: 70 kOhm - max value for the pull-down: 130 kOhm Use 60 kOhm in the pinctrl-meson driver as well so it's shown in the debugfs output. It may not be accurate for Meson8/8b/8m2 but in reality 60 kOhm is closer to the actual value than 1 Ohm. Signed-off-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/20250329190132.855196-1-martin.blumenstingl@googlemail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5863bd44ed2fa27c6bb7b3f2b7bf9450b67e02d2 Author: Ritesh Harjani (IBM) Date: Mon Mar 10 07:44:09 2025 -0500 book3s64/radix: Fix compile errors when CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP=n [ Upstream commit 29bdc1f1c1df80868fb35bc69d1f073183adc6de ] Fix compile errors when CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP=n Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Donet Tom Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/8231763344223c193e3452eab0ae8ea966aff466.1741609795.git.donettom@linux.ibm.com Signed-off-by: Sasha Levin commit b5aa85b9b0c4c7c6db39c31a56b01aaa331a5589 Author: Chenyuan Yang Date: Sun Apr 6 16:08:54 2025 -0500 ASoC: imx-card: Adjust over allocation of memory in imx_card_parse_of() [ Upstream commit a9a69c3b38c89d7992fb53db4abb19104b531d32 ] Incorrect types are used as sizeof() arguments in devm_kcalloc(). It should be sizeof(dai_link_data) for link_data instead of sizeof(snd_soc_dai_link). This is found by our static analysis tool. Signed-off-by: Chenyuan Yang Link: https://patch.msgid.link/20250406210854.149316-1-chenyuan0y@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9fddd1f15465ffa53aa533a65b57492d9667cc41 Author: Jessica Zhang Date: Mon Dec 16 16:43:14 2024 -0800 drm: Add valid clones check [ Upstream commit 41b4b11da02157c7474caf41d56baae0e941d01a ] Check that all encoders attached to a given CRTC are valid possible_clones of each other. Signed-off-by: Jessica Zhang Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-3-fe220297a7f0@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 08150a6c83a9a8e6667eb9db75561ae5c8c16e92 Author: Douglas Anderson Date: Thu Jan 9 14:28:53 2025 -0800 drm/panel-edp: Add Starry 116KHD024006 [ Upstream commit 749b5b279e5636cdcef51e15d67b77162cca6caa ] We have a few reports of sc7180-trogdor-pompom devices that have a panel in them that IDs as STA 0x0004 and has the following raw EDID: 00 ff ff ff ff ff ff 00 4e 81 04 00 00 00 00 00 10 20 01 04 a5 1a 0e 78 0a dc dd 96 5b 5b 91 28 1f 52 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 8e 1c 56 a0 50 00 1e 30 28 20 55 00 00 90 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe 00 31 31 36 4b 48 44 30 32 34 30 30 36 0a 00 e6 We've been unable to locate a datasheet for this panel and our partner has not been responsive, but all Starry eDP datasheets that we can find agree on the same timing (delay_100_500_e200) so it should be safe to use that here instead of the super conservative timings. We'll still go a little extra conservative and allow `hpd_absent` of 200 instead of 100 because that won't add any real-world delay in most cases. We'll associate the string from the EDID ("116KHD024006") with this panel. Given that the ID is the suspicious value of 0x0004 it seems likely that Starry doesn't always update their IDs but the string will still work to differentiate if we ever need to in the future. Reviewed-by: Neil Armstrong Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20250109142853.1.Ibcc3009933fd19507cc9c713ad0c99c7a9e4fe17@changeid Signed-off-by: Sasha Levin commit aa52c70ae1322430da509e5ee98f817f2dcae2ed Author: Lin.Cao Date: Thu Dec 26 12:31:15 2024 +0530 drm/buddy: fix issue that force_merge cannot free all roots [ Upstream commit 467dce3817bd2b62ccd6fcfd7aae76f242ac907e ] If buddy manager have more than one roots and each root have sub-block need to be free. When drm_buddy_fini called, the first loop of force_merge will merge and free all of the sub block of first root, which offset is 0x0 and size is biggest(more than have of the mm size). In subsequent force_merge rounds, if we use 0 as start and use remaining mm size as end, the block of other roots will be skipped in __force_merge function. It will cause the other roots can not be freed. Solution: use roots' offset as the start could fix this issue. Signed-off-by: Lin.Cao Signed-off-by: Arunpravin Paneer Selvam Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20241226070116.309290-1-Arunpravin.PaneerSelvam@amd.com Signed-off-by: Sasha Levin commit 135105287781eb6693f0075c63c0b3e6d68f7e62 Author: Simona Vetter Date: Wed Jan 8 18:24:16 2025 +0100 drm/atomic: clarify the rules around drm_atomic_state->allow_modeset [ Upstream commit c5e3306a424b52e38ad2c28c7f3399fcd03e383d ] msm is automagically upgrading normal commits to full modesets, and that's a big no-no: - for one this results in full on->off->on transitions on all these crtc, at least if you're using the usual helpers. Which seems to be the case, and is breaking uapi - further even if the ctm change itself would not result in flicker, this can hide modesets for other reasons. Which again breaks the uapi v2: I forgot the case of adding unrelated crtc state. Add that case and link to the existing kerneldoc explainers. This has come up in an irc discussion with Manasi and Ville about intel's bigjoiner mode. Also cc everyone involved in the msm irc discussion, more people joined after I sent out v1. v3: Wording polish from Pekka and Thomas Acked-by: Pekka Paalanen Acked-by: Dmitry Baryshkov Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Pekka Paalanen Cc: Rob Clark Cc: Simon Ser Cc: Manasi Navare Cc: Ville Syrjälä Cc: Abhinav Kumar Cc: Dmitry Baryshkov Signed-off-by: Simona Vetter Signed-off-by: Simona Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20250108172417.160831-1-simona.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 6ceef704e2bcef5c75be418ee06699158b3000bd Author: Oak Zeng Date: Fri Jan 10 16:01:37 2025 -0500 drm/xe: Reject BO eviction if BO is bound to current VM [ Upstream commit 0af944f0e3082ff517958b1cea76fb9b8cb379dd ] This is a follow up fix for https://patchwork.freedesktop.org/patch/msgid/20241203021929.1919730-1-oak.zeng@intel.com The overall goal is to fail vm_bind when there is memory pressure. See more details in the commit message of above patch. Abbove patch fixes the issue when user pass in a vm_id parameter during gem_create. If user doesn't pass in a vm_id during gem_create, above patch doesn't help. This patch further reject BO eviction (which could be triggered by bo validation) if BO is bound to the current VM. vm_bind could fail due to the eviction failure. The BO to VM reverse mapping structure is used to determine whether BO is bound to VM. v2: Move vm_bo definition from function scope to if(evict) clause (Thomas) Further constraint the condition by adding ctx->resv (Thomas) Add a short comment describe the change. Suggested-by: Thomas Hellström Signed-off-by: Oak Zeng Reviewed-by: Thomas Hellström Signed-off-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20250110210137.3181576-1-oak.zeng@intel.com Signed-off-by: Sasha Levin commit 650c1769cfe9df648d212322d34f4c30b284d85c Author: Michal Wajdeczko Date: Fri Dec 20 20:41:54 2024 +0100 drm/xe/sa: Always call drm_suballoc_manager_fini() [ Upstream commit 9cd3f4efc870463f17f6c29114c61fb6bfcaa291 ] After successful call to drm_suballoc_manager_init() we should make sure to call drm_suballoc_manager_fini() as it may include some cleanup code even if we didn't start using it for real. As we can abort init() early due to kvzalloc() failure, we should either explicitly call drm_suballoc_manager_fini() or, even better, postpone drm_suballoc_manager_init() once we finish all other preparation steps, so we can rely on fini() that will do cleanup. Signed-off-by: Michal Wajdeczko Cc: Matthew Brost Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20241220194205.995-2-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit 1cc37163730aa0b6ff7c5cdf51c72aa24e9de91c Author: Ching-Te Ku Date: Fri Jan 10 09:54:15 2025 +0800 wifi: rtw89: coex: Separated Wi-Fi connecting event from Wi-Fi scan event [ Upstream commit 4a57346652154bb339c48b41166df9154cff33f5 ] Wi-Fi connecting process don't need to assign to firmware slot control, if assign firmware slot control for Wi-Fi connecting event, firmware will not toggle slots because driver don't tell the slot schedule to firmware. Wi-Fi connecting event end should also cancel the 4way handshake status. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250110015416.10704-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit c9db43696ed0e2f834d1a525a6bf8433374ad3c2 Author: Maarten Lankhorst Date: Tue Dec 10 09:31:11 2024 +0100 drm/xe: Do not attempt to bootstrap VF in execlists mode [ Upstream commit f3b59457808f61d88178b0afa67cbd017d7ce79e ] It was mentioned in a review that there is a possibility of choosing to load the module with VF in execlists mode. Of course this doesn't work, just bomb out as hard as possible. Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-12-dev@lankhorst.se Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 274ae1044bd2cd637a05295713eb5ce49001e5cc Author: Maarten Lankhorst Date: Tue Dec 10 09:31:03 2024 +0100 drm/xe: Move suballocator init to after display init [ Upstream commit 380b0cdaa76bc8f5c16db16eaf48751e792ff041 ] No allocations should be done before we have had a chance to preserve the display fb. Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-4-dev@lankhorst.se Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 115360031be90aa6cf11d718caf19fea94824285 Author: P Praneesh Date: Sun Jan 19 22:12:19 2025 +0530 wifi: ath11k: Use dma_alloc_noncoherent for rx_tid buffer allocation [ Upstream commit eeadc6baf8b3dcd32787cc84f0473dc2a2850370 ] Currently, the driver allocates cacheable DMA buffers for the rx_tid structure using kzalloc() and dma_map_single(). These buffers are long-lived and can persist for the lifetime of the peer, which is not advisable. Instead of using kzalloc() and dma_map_single() for allocating cacheable DMA buffers, utilize the dma_alloc_noncoherent() helper for the allocation of long-lived cacheable DMA buffers, such as the peer's rx_tid. Since dma_alloc_noncoherent() returns unaligned physical and virtual addresses, align them internally before use within the driver. This ensures proper allocation of non-coherent memory through the kernel helper. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: P Praneesh Tested-by: Tim Harvey Link: https://patch.msgid.link/20250119164219.647059-3-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e1fffcd1d75db23797a842ccbd5ef9439e6a419d Author: Zhi Wang Date: Fri Jan 24 10:29:50 2025 -0800 drm/nouveau: fix the broken marco GSP_MSG_MAX_SIZE [ Upstream commit bbae6680cfe38b033250b483722e60ccd865976f ] The macro GSP_MSG_MAX_SIZE refers to another macro that doesn't exist. It represents the max GSP message element size. Fix the broken marco so it can be used to replace some magic numbers in the code. Signed-off-by: Zhi Wang Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20250124182958.2040494-8-zhiw@nvidia.com Signed-off-by: Sasha Levin commit 878ccaf79c95f0732b90479da0ac683052c7aec1 Author: Olivier Moysan Date: Wed Jan 8 18:03:54 2025 +0100 drm: bridge: adv7511: fill stream capabilities [ Upstream commit c852646f12d4cd5b4f19eeec2976c5d98c0382f8 ] Set no_i2s_capture and no_spdif_capture flags in hdmi_codec_pdata structure to report that the ADV7511 HDMI bridge does not support i2s or spdif audio capture. Signed-off-by: Olivier Moysan Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20250108170356.413063-2-olivier.moysan@foss.st.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fb0d82562c07806c7b337c222c69f3c3323c01e1 Author: P Praneesh Date: Mon Dec 23 11:31:25 2024 +0530 wifi: ath12k: Fix end offset bit definition in monitor ring descriptor [ Upstream commit 6788a666000d600bd8f2e9f991cad9cc805e7f01 ] End offset for the monitor destination ring descriptor is defined as 16 bits, while the firmware definition specifies only 12 bits. The remaining bits (bit 12 to bit 15) are reserved and may contain junk values, leading to invalid information retrieval. Fix this issue by updating the correct genmask values. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh Link: https://patch.msgid.link/20241223060132.3506372-8-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit bb2d55681ee70eaabd88fe1e04c35f681ec3586d Author: Aaradhana Sahu Date: Thu Jan 16 08:58:35 2025 +0530 wifi: ath12k: Fetch regdb.bin file from board-2.bin [ Upstream commit 24f587572acf7509127dbdfcbf1b681ef84eeba0 ] Currently, ath12k_core_fetch_regdb() finds regdb.bin file through board id's but in board-2.bin file regdb.bin file is present with default board id because of which regdb.bin is not fetched. Add support to fetch regdb.bin file from board-2.bin through default board id. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250116032835.118397-1-quic_aarasahu@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit a3f6e4682f3d4bd811a588713f27133ca57e049b Author: Rosen Penev Date: Tue Nov 5 14:23:26 2024 -0800 wifi: ath9k: return by of_get_mac_address [ Upstream commit dfffb317519f88534bb82797f055f0a2fd867e7b ] When using nvmem, ath9k could potentially be loaded before nvmem, which loads after mtd. This is an issue if DT contains an nvmem mac address. If nvmem is not ready in time for ath9k, -EPROBE_DEFER is returned. Pass it to _probe so that ath9k can properly grab a potentially present MAC address. Signed-off-by: Rosen Penev Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20241105222326.194417-1-rosenp@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 331c0af96c0347be253f5f5610530d3ab819dc33 Author: Michal Wajdeczko Date: Wed Jan 29 20:59:47 2025 +0100 drm/xe/pf: Reset GuC VF config when unprovisioning critical resource [ Upstream commit 33f17e2cbd930a2a00eb007d9b241b6db010a880 ] GuC firmware counts received VF configuration KLVs and may start validation of the complete VF config even if some resources where unprovisioned in the meantime, leading to unexpected errors like: $ echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/contexts_quota $ echo 0 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/contexts_quota $ echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/doorbells_quota $ echo 0 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/doorbells_quota $ echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/ggtt_quota tee: '/sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/ggtt_quota': Input/output error To mitigate this problem trigger explicit VF config reset after unprovisioning any of the critical resources (GGTT, context or doorbell IDs) that GuC is monitoring. Signed-off-by: Michal Wajdeczko Reviewed-by: Michał Winiarski Link: https://patchwork.freedesktop.org/patch/msgid/20250129195947.764-3-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit 63780d7352f0f36c900c29b8a134cdf23dd1f534 Author: Youssef Samir Date: Fri Jan 17 10:09:41 2025 -0700 accel/qaic: Mask out SR-IOV PCI resources [ Upstream commit 8685520474bfc0fe4be83c3cbfe3fb3e1ca1514a ] During the initialization of the qaic device, pci_select_bars() is used to fetch a bitmask of the BARs exposed by the device. On devices that have Virtual Functions capabilities, the bitmask includes SR-IOV BARs. Use a mask to filter out SR-IOV BARs if they exist. Signed-off-by: Youssef Samir Reviewed-by: Jeffrey Hugo Signed-off-by: Jeffrey Hugo Reviewed-by: Lizhi Hou Link: https://patchwork.freedesktop.org/patch/msgid/20250117170943.2643280-6-quic_jhugo@quicinc.com Signed-off-by: Sasha Levin commit a1e3f2ea66c0ddb62cfa25fba6153c6ed3d63eb4 Author: Nicolas Escande Date: Mon Jan 27 08:13:06 2025 +0100 wifi: ath12k: fix ath12k_hal_tx_cmd_ext_desc_setup() info1 override [ Upstream commit df11edfba49e5fb69f4c9e7cb76082b89c417f78 ] Since inception there is an obvious typo laying around in ath12k_hal_tx_cmd_ext_desc_setup(). Instead of initializing + adding flags to tcl_ext_cmd->info1, we initialize + override. This will be needed in the future to make broadcast frames work with ethernet encapsulation. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nicolas Escande Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250127071306.1454699-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit ff56fbf50eff94a5f26a966b855e481765e02e95 Author: Isaac Scott Date: Tue Jan 28 17:31:43 2025 +0000 regulator: ad5398: Add device tree support [ Upstream commit 5a6a461079decea452fdcae955bccecf92e07e97 ] Previously, the ad5398 driver used only platform_data, which is deprecated in favour of device tree. This caused the AD5398 to fail to probe as it could not load its init_data. If the AD5398 has a device tree node, pull the init_data from there using of_get_regulator_init_data. Signed-off-by: Isaac Scott Acked-by: Michael Hennerich Link: https://patch.msgid.link/20250128173143.959600-4-isaac.scott@ideasonboard.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 697a6f8a91063cfd47c330c81281e42ef398ea97 Author: Sean Anderson Date: Thu Jan 16 17:41:30 2025 -0500 spi: zynqmp-gqspi: Always acknowledge interrupts [ Upstream commit 89785306453ce6d949e783f6936821a0b7649ee2 ] RXEMPTY can cause an IRQ, even though we may not do anything about it (such as if we are waiting for more received data). We must still handle these IRQs because we can tell they were caused by the device. Signed-off-by: Sean Anderson Link: https://patch.msgid.link/20250116224130.2684544-6-sean.anderson@linux.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c533839e0a48daaba4820c5596735911a230dadc Author: Ping-Ke Shih Date: Wed Jan 22 14:03:01 2025 +0800 wifi: rtw89: add wiphy_lock() to work that isn't held wiphy_lock() yet [ Upstream commit ebfc9199df05d37b67f4d1b7ee997193f3d2e7c8 ] To ensure where are protected by driver mutex can also be protected by wiphy_lock(), so afterward we can remove driver mutex safely. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250122060310.31976-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 9e9e9749159087894bcd31fee866ce2d7cb833d3 Author: Bitterblue Smith Date: Sun Jan 26 16:03:11 2025 +0200 wifi: rtw88: Don't use static local variable in rtw8822b_set_tx_power_index_by_rate [ Upstream commit 00451eb3bec763f708e7e58326468c1e575e5a66 ] Some users want to plug two identical USB devices at the same time. This static variable could theoretically cause them to use incorrect TX power values. Move the variable to the caller and pass a pointer to it to rtw8822b_set_tx_power_index_by_rate(). Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/8a60f581-0ab5-4d98-a97d-dd83b605008f@gmail.com Signed-off-by: Sasha Levin commit 0b63d246248f51c211a0626e28f762969343a677 Author: Soeren Moch Date: Mon Jan 27 20:48:28 2025 +0100 wifi: rtl8xxxu: retry firmware download on error [ Upstream commit 3d3e28feca7ac8c6cf2a390dbbe1f97e3feb7f36 ] Occasionally there is an EPROTO error during firmware download. This error is converted to EAGAIN in the download function. But nobody tries again and so device probe fails. Implement download retry to fix this. This error was observed (and fix tested) on a tbs2910 board [1] with an embedded RTL8188EU (0bda:8179) device behind a USB hub. [1] arch/arm/boot/dts/nxp/imx/imx6q-tbs2910.dts Signed-off-by: Soeren Moch Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250127194828.599379-1-smoch@web.de Signed-off-by: Sasha Levin commit ff5c6e3d251ea13f28a8e4ba39e8cf2ee003a5d4 Author: Lad Prabhakar Date: Mon Dec 16 21:02:01 2024 +0000 clk: renesas: rzg2l-cpg: Refactor Runtime PM clock validation [ Upstream commit f6f73b891bf6beff069fcacc7b4a796e1009bf26 ] Refactor rzg2l_cpg_attach_dev to delegate clock validation for Runtime PM to the updated rzg2l_cpg_is_pm_clk function. Ensure validation of clocks associated with the power domain while excluding external and core clocks. Prevent incorrect Runtime PM management for clocks outside the domain's scope. Update rzg2l_cpg_is_pm_clk to operate on a per-power-domain basis. Verify clkspec.np against the domain's device node, check argument validity, and validate clock type (CPG_MOD). Use the no_pm_mod_clks array to exclude specific clocks from PM management. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20241216210201.239855-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 3a95341c65e4e80eac8d3221f944d27ea6e9d7c7 Author: Ravi Bangoria Date: Wed Jan 15 05:44:32 2025 +0000 perf/amd/ibs: Fix ->config to sample period calculation for OP PMU [ Upstream commit 598bdf4fefff5af4ce6d26d16f7b2a20808fc4cb ] Instead of using standard perf_event_attr->freq=0 and ->sample_period fields, IBS event in 'sample period mode' can also be opened by setting period value directly in perf_event_attr->config in a MaxCnt bit-field format. IBS OP MaxCnt bits are defined as: (high bits) IbsOpCtl[26:20] = IbsOpMaxCnt[26:20] (low bits) IbsOpCtl[15:0] = IbsOpMaxCnt[19:4] Perf event sample period can be derived from MaxCnt bits as: sample_period = (high bits) | ((low_bits) << 4); However, current code just masks MaxCnt bits and shifts all of them, including high bits, which is incorrect. Fix it. Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://lkml.kernel.org/r/20250115054438.1021-4-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit e225dbb03af653ff3ab97908e96bcde9882f839d Author: Ravi Bangoria Date: Wed Jan 15 05:44:33 2025 +0000 perf/amd/ibs: Fix perf_ibs_op.cnt_mask for CurCnt [ Upstream commit 46dcf85566170d4528b842bf83ffc350d71771fa ] IBS Op uses two counters: MaxCnt and CurCnt. MaxCnt is programmed with the desired sample period. IBS hw generates sample when CurCnt reaches to MaxCnt. The size of these counter used to be 20 bits but later they were extended to 27 bits. The 7 bit extension is indicated by CPUID Fn8000_001B_EAX[6 / OpCntExt]. perf_ibs->cnt_mask variable contains bit masks for MaxCnt and CurCnt. But IBS driver does not set upper 7 bits of CurCnt in cnt_mask even when OpCntExt CPUID bit is set. Fix this. IBS driver uses cnt_mask[CurCnt] bits only while disabling an event. Fortunately, CurCnt bits are not read from MSR while re-enabling the event, instead MaxCnt is programmed with desired period and CurCnt is set to 0. Hence, we did not see any issues so far. Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://lkml.kernel.org/r/20250115054438.1021-5-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit 46f1c2b508e3309e6f2a121e045f0e11571974c3 Author: Sudeep Holla Date: Fri Jan 31 14:18:20 2025 +0000 firmware: arm_scmi: Relax duplicate name constraint across protocol ids [ Upstream commit 21ee965267bcbdd733be0f35344fa0f0226d7861 ] Currently in scmi_protocol_device_request(), no duplicate scmi device name is allowed across any protocol. However scmi_dev_match_id() first matches the protocol id and then the name. So, there is no strict requirement to keep this scmi device name unique across all the protocols. Relax the constraint on the duplicate name across the protocols and inhibit only within the same protocol id. Message-Id: <20250131141822.514342-1-sudeep.holla@arm.com> Reviewed-by: Dhruva Gole Reviewed-by: Peng Fan Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit ff84436446a022072bafc6a8ec30e4d5fa078d09 Author: Viktor Malik Date: Wed Jan 29 08:18:57 2025 +0100 bpftool: Fix readlink usage in get_fd_type [ Upstream commit 0053f7d39d491b6138d7c526876d13885cbb65f1 ] The `readlink(path, buf, sizeof(buf))` call reads at most sizeof(buf) bytes and *does not* append null-terminator to buf. With respect to that, fix two pieces in get_fd_type: 1. Change the truncation check to contain sizeof(buf) rather than sizeof(path). 2. Append null-terminator to buf. Reported by Coverity. Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20250129071857.75182-1-vmalik@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c80b2d159c31fa5be7daff9f1572757481e916c9 Author: Martin KaFai Lau Date: Mon Jan 27 14:27:19 2025 -0800 bpf: Use kallsyms to find the function name of a struct_ops's stub function [ Upstream commit 12fdd29d5d71d2987a1aec434b704d850a4d7fcb ] In commit 1611603537a4 ("bpf: Create argument information for nullable arguments."), it introduced a "__nullable" tagging at the argument name of a stub function. Some background on the commit: it requires to tag the stub function instead of directly tagging the "ops" of a struct. This is because the btf func_proto of the "ops" does not have the argument name and the "__nullable" is tagged at the argument name. To find the stub function of a "ops", it currently relies on a naming convention on the stub function "st_ops__ops_name". e.g. tcp_congestion_ops__ssthresh. However, the new kernel sub system implementing bpf_struct_ops have missed this and have been surprised that the "__nullable" and the to-be-landed "__ref" tagging was not effective. One option would be to give a warning whenever the stub function does not follow the naming convention, regardless if it requires arg tagging or not. Instead, this patch uses the kallsyms_lookup approach and removes the requirement on the naming convention. The st_ops->cfi_stubs has all the stub function kernel addresses. kallsyms_lookup() is used to lookup the function name. With the function name, BTF can be used to find the BTF func_proto. The existing "__nullable" arg name searching logic will then fall through. One notable change is, if it failed in kallsyms_lookup or it failed in looking up the stub function name from the BTF, the bpf_struct_ops registration will fail. This is different from the previous behavior that it silently ignored the "st_ops__ops_name" function not found error. The "tcp_congestion_ops", "sched_ext_ops", and "hid_bpf_ops" can still be registered successfully after this patch. There is struct_ops_maybe_null selftest to cover the "__nullable" tagging. Other minor changes: 1. Removed the "%s__%s" format from the pr_warn because the naming convention is removed. 2. The existing bpf_struct_ops_supported() is also moved earlier because prepare_arg_info needs to use it to decide if the stub function is NULL before calling the prepare_arg_info. Cc: Tejun Heo Cc: Benjamin Tissoires Cc: Yonghong Song Cc: Amery Hung Signed-off-by: Martin KaFai Lau Reviewed-by: Amery Hung Link: https://lore.kernel.org/r/20250127222719.2544255-1-martin.lau@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c3fd672e6644a30597abcb44fc867723d4ac6f6b Author: Thomas Zimmermann Date: Fri Jan 31 10:21:08 2025 +0100 drm/ast: Find VBIOS mode from regular display size [ Upstream commit c81202906b5cd56db403e95db3d29c9dfc8c74c1 ] The ast driver looks up supplied display modes from an internal list of display modes supported by the VBIOS. Do not use the crtc_-prefixed display values from struct drm_display_mode for looking up the VBIOS mode. The fields contain raw values that the driver programs to hardware. They are affected by display settings like double-scan or interlace. Instead use the regular vdisplay and hdisplay fields for lookup. As the programmed values can now differ from the values used for lookup, set struct drm_display_mode.crtc_vdisplay and .crtc_hdisplay from the VBIOS mode. Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-9-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 538a82168e52bdefe98f39ada155cd06a0679fa6 Author: Matthew Sakai Date: Wed Jan 29 18:26:05 2025 -0500 dm vdo: use a short static string for thread name prefix [ Upstream commit 3280c9313c9adce01550cc9f00edfb1dc7c744da ] Also remove MODULE_NAME and a BUG_ON check, both unneeded. This fixes a warning about string truncation in snprintf that will never happen in practice: drivers/md/dm-vdo/vdo.c: In function ‘vdo_make’: drivers/md/dm-vdo/vdo.c:564:5: error: ‘%s’ directive output may be truncated writing up to 55 bytes into a region of size 16 [-Werror=format-truncation=] "%s%u", MODULE_NAME, instance); ^~ drivers/md/dm-vdo/vdo.c:563:2: note: ‘snprintf’ output between 2 and 66 bytes into a destination of size 16 snprintf(vdo->thread_name_prefix, sizeof(vdo->thread_name_prefix), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s%u", MODULE_NAME, instance); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reported-by: John Garry Reviewed-by: John Garry Signed-off-by: Matthew Sakai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit f8b4edbcf353117acd5f63702d9ea53c820b2365 Author: Chung Chung Date: Wed Jan 29 18:27:12 2025 -0500 dm vdo indexer: prevent unterminated string warning [ Upstream commit f4e99b846c90163d350c69d6581ac38dd5818eb8 ] Fix array initialization that triggers a warning: error: initializer-string for array of ‘unsigned char’ is too long [-Werror=unterminated-string-initialization] Signed-off-by: Chung Chung Signed-off-by: Matthew Sakai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 0cc2aa747208558c618e5afe06df8362eaf7b9e5 Author: Vladimir Kondratiev Date: Wed Jan 29 11:16:37 2025 +0200 irqchip/riscv-aplic: Add support for hart indexes [ Upstream commit b93afe8a3ac53ae52296d65acfaa9c5f582a48cc ] RISC-V APLIC specification defines "hart index" in: https://github.com/riscv/riscv-aia Within a given interrupt domain, each of the domain’s harts has a unique index number in the range 0 to 2^14 − 1 (= 16,383). The index number a domain associates with a hart may or may not have any relationship to the unique hart identifier (“hart ID”) that the RISC-V Privileged Architecture assigns to the hart. Two different interrupt domains may employ entirely different index numbers for the same set of harts. Further, this document says in "4.5 Memory-mapped control region for an interrupt domain": The array of IDC structures may include some for potential hart index numbers that are not actual hart index numbers in the domain. For example, the first IDC structure is always for hart index 0, but 0 is not necessarily a valid index number for any hart in the domain. Support arbitrary hart indices specified in an optional APLIC property "riscv,hart-indexes" which is specified as an array of u32 elements, one per interrupt target. If this property is not specified, fallback to use logical hart indices within the domain. Signed-off-by: Vladimir Kondratiev Signed-off-by: Thomas Gleixner Reviewed-by: Anup Patel Link: https://lore.kernel.org/all/20250129091637.1667279-3-vladimir.kondratiev@mobileye.com Signed-off-by: Sasha Levin commit a3300021d4875391f356d03432635828c9c75522 Author: Charles Keepax Date: Tue Jan 7 15:44:07 2025 +0000 ASoC: rt722-sdca: Add some missing readable registers [ Upstream commit f9a5c4b6afc79073491acdab7f1e943ee3a19fbb ] Add a few missing registers from the readable register callback. Suggested-by: Shuming Fan Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20250107154408.814455-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 67f7080cb30e5e1f0b38cc2f33c9c86416e42311 Author: Cezary Rojewski Date: Mon Feb 3 15:10:43 2025 +0100 ASoC: codecs: pcm3168a: Allow for 24-bit in provider mode [ Upstream commit 7d92a38d67e5d937b64b20aa4fd14451ee1772f3 ] As per codec device specification, 24-bit is allowed in provider mode. Update the code to reflect that. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250203141051.2361323-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b99c2faf4021596a7ededb92a7224b60ff6cf0bd Author: Naman Trivedi Date: Fri Nov 22 01:57:12 2024 -0800 arm64: zynqmp: add clock-output-names property in clock nodes [ Upstream commit 385a59e7f7fb3438466a0712cc14672c708bbd57 ] Add clock-output-names property to clock nodes, so that the resulting clock name do not change when clock node name is changed. Also, replace underscores with hyphens in the clock node names as per dt-schema rule. Signed-off-by: Naman Trivedi Acked-by: Senthil Nathan Thangaraj Link: https://lore.kernel.org/r/20241122095712.1166883-1-naman.trivedimanojbhai@amd.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 9e3eaf7f750e1048cabd0e186fc56abb2bc6d054 Author: junan Date: Thu Nov 28 10:35:18 2024 +0800 HID: usbkbd: Fix the bit shift number for LED_KANA [ Upstream commit d73a4bfa2881a6859b384b75a414c33d4898b055 ] Since "LED_KANA" was defined as "0x04", the shift number should be "4". Signed-off-by: junan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b5a1ef646ce135a8d4c12b48fe35de26e7c58b32 Author: Avula Sri Charan Date: Fri Jan 24 14:30:58 2025 +0530 wifi: ath12k: Avoid napi_sync() before napi_enable() [ Upstream commit 268c73d470a5790a492a2fc2ded084b909d144f3 ] In case of MHI error a reset work will be queued which will try napi_disable() after napi_synchronize(). As the napi will be only enabled after qmi_firmware_ready event, trying napi_synchronize() before napi_enable() will result in indefinite sleep in case of a firmware crash in QMI init sequence. To avoid this, introduce napi_enabled flag to check if napi is enabled or not before calling napi_synchronize(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Avula Sri Charan Signed-off-by: Tamizh Chelvam Raja Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250124090058.3194299-1-quic_tamizhr@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit dbb6efb3d8f34a2f2b4b0cb959ef74499f1794bf Author: Kai Mäkisara Date: Mon Jan 20 21:49:22 2025 +0200 scsi: st: Restore some drive settings after reset [ Upstream commit 7081dc75df79696d8322d01821c28e53416c932c ] Some of the allowed operations put the tape into a known position to continue operation assuming only the tape position has changed. But reset sets partition, density and block size to drive default values. These should be restored to the values before reset. Normally the current block size and density are stored by the drive. If the settings have been changed, the changed values have to be saved by the driver across reset. Signed-off-by: Kai Mäkisara Link: https://lore.kernel.org/r/20250120194925.44432-2-Kai.Makisara@kolumbus.fi Reviewed-by: John Meneghini Tested-by: John Meneghini Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1be28b37a6a7b4cfc614caa3cb0ffa2b0cf2fce0 Author: Justin Tee Date: Thu Jan 30 16:05:20 2025 -0800 scsi: lpfc: Free phba irq in lpfc_sli4_enable_msi() when pci_irq_vector() fails [ Upstream commit f0842902b383982d1f72c490996aa8fc29a7aa0d ] Fix smatch warning regarding missed calls to free_irq(). Free the phba IRQ in the failed pci_irq_vector cases. lpfc_init.c: lpfc_sli4_enable_msi() warn: 'phba->pcidev->irq' from request_irq() not released. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20250131000524.163662-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 609bc6e9c1869b478c0d7e803a5ff8fe15d291e9 Author: Justin Tee Date: Thu Jan 30 16:05:21 2025 -0800 scsi: lpfc: Ignore ndlp rport mismatch in dev_loss_tmo callbk [ Upstream commit 23ed62897746f49f195d819ce6edeb1db27d1b72 ] With repeated port swaps between separate fabrics, there can be multiple registrations for fabric well known address 0xfffffe. This can cause ndlp reference confusion due to the usage of a single ndlp ptr that stores the rport object in fc_rport struct private storage during transport registration. Subsequent registrations update the ndlp->rport field with the newer rport, so when transport layer triggers dev_loss_tmo for the earlier registered rport the ndlp->rport private storage is referencing the newer rport instead of the older rport in dev_loss_tmo callbk. Because the older ndlp->rport object is already cleaned up elsewhere in driver code during the time of fabric swap, check that the rport provided in dev_loss_tmo callbk actually matches the rport stored in the LLDD's ndlp->rport field. Otherwise, skip dev_loss_tmo work on a stale rport. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20250131000524.163662-4-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c670902775c2000e956c83a39d8bfb3cf8dd6535 Author: Justin Tee Date: Thu Jan 30 16:05:22 2025 -0800 scsi: lpfc: Handle duplicate D_IDs in ndlp search-by D_ID routine [ Upstream commit 56c3d809b7b450379162d0b8a70bbe71ab8db706 ] After a port swap between separate fabrics, there may be multiple nodes in the vport's fc_nodes list with the same fabric well known address. Duplication is temporary and eventually resolves itself after dev_loss_tmo expires, but nameserver queries may still occur before dev_loss_tmo. This possibly results in returning stale fabric ndlp objects. Fix by adding an nlp_state check to ensure the ndlp search routine returns the correct newer allocated ndlp fabric object. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20250131000524.163662-5-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f5ce5628576dd8d7fdce265ee642f1b6d48cfc0b Author: Konstantin Taranov Date: Mon Jan 20 09:27:14 2025 -0800 net/mana: fix warning in the writer of client oob [ Upstream commit 5ec7e1c86c441c46a374577bccd9488abea30037 ] Do not warn on missing pad_data when oob is in sgl. Signed-off-by: Konstantin Taranov Link: https://patch.msgid.link/1737394039-28772-9-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Shiraz Saleem Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 7cc781374e20e8198f388fd0b6a1e2af58d36740 Author: Michal Wajdeczko Date: Fri Jan 31 16:37:13 2025 +0100 drm/xe/relay: Don't use GFP_KERNEL for new transactions [ Upstream commit 78d5d1e20d1de9422f013338a0f2311448588ba7 ] VFs use a relay transaction during the resume/reset flow and use of the GFP_KERNEL flag may conflict with the reclaim: -> #0 (fs_reclaim){+.+.}-{0:0}: [ ] __lock_acquire+0x1874/0x2bc0 [ ] lock_acquire+0xd2/0x310 [ ] fs_reclaim_acquire+0xc5/0x100 [ ] mempool_alloc_noprof+0x5c/0x1b0 [ ] __relay_get_transaction+0xdc/0xa10 [xe] [ ] relay_send_to+0x251/0xe50 [xe] [ ] xe_guc_relay_send_to_pf+0x79/0x3a0 [xe] [ ] xe_gt_sriov_vf_connect+0x90/0x4d0 [xe] [ ] xe_uc_init_hw+0x157/0x3b0 [xe] [ ] do_gt_restart+0x1ae/0x650 [xe] [ ] xe_gt_resume+0xb6/0x120 [xe] [ ] xe_pm_runtime_resume+0x15b/0x370 [xe] [ ] xe_pci_runtime_resume+0x73/0x90 [xe] [ ] pci_pm_runtime_resume+0xa0/0x100 [ ] __rpm_callback+0x4d/0x170 [ ] rpm_callback+0x64/0x70 [ ] rpm_resume+0x594/0x790 [ ] __pm_runtime_resume+0x4e/0x90 [ ] xe_pm_runtime_get_ioctl+0x9c/0x160 [xe] Since we have a preallocated pool of relay transactions, which should cover all our normal relay use cases, we may use the GFP_NOWAIT flag when allocating new outgoing transactions. Signed-off-by: Michal Wajdeczko Tested-by: Marcin Bernatowicz Reviewed-by: Marcin Bernatowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250131153713.808-1-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit e2017f44c6d4aaa4450cf515a4006c2ef7e8c6d1 Author: Michal Swiatkowski Date: Tue Dec 3 07:58:09 2024 +0100 ice: count combined queues using Rx/Tx count [ Upstream commit c3a392bdd31adc474f1009ee85c13fdd01fe800d ] Previous implementation assumes that there is 1:1 matching between vectors and queues. It isn't always true. Get minimum value from Rx/Tx queues to determine combined queues number. Reviewed-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy Signed-off-by: Michal Swiatkowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 887e39ac4704e2285dc3622e1ea40cd3130199d2 Author: Peter Zijlstra (Intel) Date: Tue Jan 21 07:23:02 2025 -0800 perf: Avoid the read if the count is already updated [ Upstream commit 8ce939a0fa194939cc1f92dbd8bc1a7806e7d40a ] The event may have been updated in the PMU-specific implementation, e.g., Intel PEBS counters snapshotting. The common code should not read and overwrite the value. The PERF_SAMPLE_READ in the data->sample_type can be used to detect whether the PMU-specific value is available. If yes, avoid the pmu->read() in the common code. Add a new flag, skip_read, to track the case. Factor out a perf_pmu_read() to clean up the code. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250121152303.3128733-3-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit d402437cde36cce8e34f32a53322b3f60ca292d2 Author: Ankur Arora Date: Thu Dec 12 20:06:52 2024 -0800 rcu: fix header guard for rcu_all_qs() [ Upstream commit ad6b5b73ff565e88aca7a7d1286788d80c97ba71 ] rcu_all_qs() is defined for !CONFIG_PREEMPT_RCU but the declaration is conditioned on CONFIG_PREEMPTION. With CONFIG_PREEMPT_LAZY, CONFIG_PREEMPTION=y does not imply CONFIG_PREEMPT_RCU=y. Decouple the two. Cc: Paul E. McKenney Reviewed-by: Frederic Weisbecker Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Ankur Arora Signed-off-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit fcabb696743a4ec2e95531a90a2c0aeec2140a36 Author: Ankur Arora Date: Thu Dec 12 20:06:55 2024 -0800 rcu: handle unstable rdp in rcu_read_unlock_strict() [ Upstream commit fcf0e25ad4c8d14d2faab4d9a17040f31efce205 ] rcu_read_unlock_strict() can be called with preemption enabled which can make for an unstable rdp and a racy norm value. Fix this by dropping the preempt-count in __rcu_read_unlock() after the call to rcu_read_unlock_strict(), adjusting the preempt-count check appropriately. Suggested-by: Frederic Weisbecker Signed-off-by: Ankur Arora Reviewed-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 5cdaa970d73a4428531ebdd31934f4f081dd3916 Author: Ankur Arora Date: Thu Dec 12 20:06:56 2024 -0800 rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y [ Upstream commit 83b28cfe796464ebbde1cf7916c126da6d572685 ] With PREEMPT_RCU=n, cond_resched() provides urgently needed quiescent states for read-side critical sections via rcu_all_qs(). One reason why this was needed: lacking preempt-count, the tick handler has no way of knowing whether it is executing in a read-side critical section or not. With (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), we get (PREEMPT_COUNT=y, PREEMPT_RCU=n). In this configuration cond_resched() is a stub and does not provide quiescent states via rcu_all_qs(). (PREEMPT_RCU=y provides this information via rcu_read_unlock() and its nesting counter.) So, use the availability of preempt_count() to report quiescent states in rcu_flavor_sched_clock_irq(). Suggested-by: Paul E. McKenney Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Ankur Arora Reviewed-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 65daba41f935e8706ded5fc0eda686bcb28c9d0a Author: Michal Swiatkowski Date: Tue Dec 3 07:58:14 2024 +0100 ice: treat dyn_allowed only as suggestion [ Upstream commit a8c2d3932c1106af2764cc6869b29bcf3cb5bc47 ] It can be needed to have some MSI-X allocated as static and rest as dynamic. For example on PF VSI. We want to always have minimum one MSI-X on it, because of that it is allocated as a static one, rest can be dynamic if it is supported. Change the ice_get_irq_res() to allow using static entries if they are free even if caller wants dynamic one. Adjust limit values to the new approach. Min and max in limit means the values that are valid, so decrease max and num_static by one. Set vsi::irq_dyn_alloc if dynamic allocation is supported. Reviewed-by: Jacob Keller Reviewed-by: Wojciech Drewek Tested-by: Pucha Himasekhar Reddy Signed-off-by: Michal Swiatkowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 3c8b4657a6d7560c5e3cc9b4d8e259ce82ac0766 Author: Michal Swiatkowski Date: Tue Dec 3 07:58:17 2024 +0100 ice: init flow director before RDMA [ Upstream commit d67627e7b53203ca150e54723abbed81a0716286 ] Flow director needs only one MSI-X. Load it before RDMA to save MSI-X for it. Reviewed-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy Signed-off-by: Michal Swiatkowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 58cdd1ee650b3e3af1b2f5ab3bf95f2005f09f4e Author: Petr Machata Date: Tue Feb 4 18:37:15 2025 +0100 bridge: mdb: Allow replace of a host-joined group [ Upstream commit d9e9f6d7b7d0c520bb87f19d2cbc57aeeb2091d5 ] Attempts to replace an MDB group membership of the host itself are currently bounced: # ip link add name br up type bridge vlan_filtering 1 # bridge mdb replace dev br port br grp 239.0.0.1 vid 2 # bridge mdb replace dev br port br grp 239.0.0.1 vid 2 Error: bridge: Group is already joined by host. A similar operation done on a member port would succeed. Ignore the check for replacement of host group memberships as well. The bit of code that this enables is br_multicast_host_join(), which, for already-joined groups only refreshes the MC group expiration timer, which is desirable; and a userspace notification, also desirable. Change a selftest that exercises this code path from expecting a rejection to expecting a pass. The rest of MDB selftests pass without modification. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/e5c5188b9787ae806609e7ca3aa2a0a501b9b5c4.1738685648.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76e56dbe508b3b5874ee069a6e50e4f6bc14ecba Author: Eric Dumazet Date: Tue Feb 4 14:48:25 2025 +0000 net: flush_backlog() small changes [ Upstream commit cbe08724c18078564abefbf6591078a7c98e5e0f ] Add READ_ONCE() around reads of skb->dev->reg_state, because this field can be changed from other threads/cpus. Instead of calling dev_kfree_skb_irq() and kfree_skb() while interrupts are masked and locks held, use a temporary list and use __skb_queue_purge_reason() Use SKB_DROP_REASON_DEV_READY drop reason to better describe why these skbs are dropped. Signed-off-by: Eric Dumazet Reviewed-by: Jason Xing Link: https://patch.msgid.link/20250204144825.316785-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba59747562c49974cbace989d76b94a8331da442 Author: Heiner Kallweit Date: Tue Feb 4 07:58:17 2025 +0100 r8169: don't scan PHY addresses > 0 [ Upstream commit faac69a4ae5abb49e62c79c66b51bb905c9aa5ec ] The PHY address is a dummy, because r8169 PHY access registers don't support a PHY address. Therefore scan address 0 only. Signed-off-by: Heiner Kallweit Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/830637dd-4016-4a68-92b3-618fcac6589d@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ded26f9e4cdbec728c6f81850cf7c2191859c03c Author: Geert Uytterhoeven Date: Tue Feb 4 22:36:54 2025 +0100 ipv4: ip_gre: Fix set but not used warning in ipgre_err() if IPv4-only [ Upstream commit 50f37fc2a39c4a8cc4813629b4cf239b71c6097d ] if CONFIG_NET_IPGRE is enabled, but CONFIG_IPV6 is disabled: net/ipv4/ip_gre.c: In function ‘ipgre_err’: net/ipv4/ip_gre.c:144:22: error: variable ‘data_len’ set but not used [-Werror=unused-but-set-variable] 144 | unsigned int data_len = 0; | ^~~~~~~~ Fix this by moving all data_len processing inside the IPV6-only section that uses its result. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202501121007.2GofXmh5-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Link: https://patch.msgid.link/d09113cfe2bfaca02f3dddf832fb5f48dd20958b.1738704881.git.geert@linux-m68k.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a6644aeb8ddf196dec5f8e782293c36f065df4d7 Author: Ido Schimmel Date: Tue Feb 4 16:55:42 2025 +0200 vxlan: Annotate FDB data races [ Upstream commit f6205f8215f12a96518ac9469ff76294ae7bd612 ] The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2]. Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE(). [1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250204145549.1216254-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 61e931ee145eeab8196e585ff4334870b130b744 Author: Dhananjay Ugwekar Date: Thu Jan 30 08:52:52 2025 +0000 cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost [ Upstream commit db1cafc77aaaf871509da06f4a864e9af6d6791f ] set_boost is a per-policy function call, hence a driver wide lock is unnecessary. Also this mutex_acquire can collide with the mutex_acquire from the mode-switch path in status_store(), which can lead to a deadlock. So, remove it. Signed-off-by: Dhananjay Ugwekar Acked-by: Mario Limonciello Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b82e496531c571caf8a2ef247f51c160bab2162e Author: Carolina Jubran Date: Mon Feb 3 23:35:16 2025 +0200 net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled [ Upstream commit 689805dcc474c2accb5cffbbcea1c06ee4a54570 ] When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns `-EINVAL` and triggers a `WARN_ON`, leading to an unnecessary call trace. Update the code to handle this case more gracefully by returning `-EOPNOTSUPP` instead, while also providing a helpful user message. Signed-off-by: Carolina Jubran Reviewed-by: Yael Chemla Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Kalesh AP Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 91526279362d3708117194ad21372ffc8806ba3f Author: Jakub Kicinski Date: Mon Feb 3 13:55:09 2025 -0800 tools: ynl-gen: don't output external constants [ Upstream commit 7e8b24e24ac46038e48c9a042e7d9b31855cbca5 ] A definition with a "header" property is an "external" definition for C code, as in it is defined already in another C header file. Other languages will need the exact value but C codegen should not recreate it. So don't output those definitions in the uAPI header. Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20250203215510.1288728-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 37c07516ac6a527ef1e577eb69cbad6028f74ce5 Author: Alexander Duyck Date: Mon Feb 3 17:00:38 2025 -0800 eth: fbnic: set IFF_UNICAST_FLT to avoid enabling promiscuous mode when adding unicast addrs [ Upstream commit 09717c28b76c30b1dc8c261c855ffb2406abab2e ] I realized when we were adding unicast addresses we were enabling promiscuous mode. I did a bit of digging and realized we had overlooked setting the driver private flag to indicate we supported unicast filtering. Example below shows the table with 00deadbeef01 as the main NIC address, and 5 additional addresses in the 00deadbeefX0 format. # cat $dbgfs/mac_addr Idx S TCAM Bitmap Addr/Mask ---------------------------------- 00 0 00000000,00000000 000000000000 000000000000 01 0 00000000,00000000 000000000000 000000000000 02 0 00000000,00000000 000000000000 000000000000 ... 24 0 00000000,00000000 000000000000 000000000000 25 1 00100000,00000000 00deadbeef50 000000000000 26 1 00100000,00000000 00deadbeef40 000000000000 27 1 00100000,00000000 00deadbeef30 000000000000 28 1 00100000,00000000 00deadbeef20 000000000000 29 1 00100000,00000000 00deadbeef10 000000000000 30 1 00100000,00000000 00deadbeef01 000000000000 31 0 00000000,00000000 000000000000 000000000000 Before rule 31 would be active. With this change it correctly sticks to just the unicast filters. Signed-off-by: Alexander Duyck Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250204010038.1404268-2-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d2b58a10228a906d46155eb7c15d79f39be25b37 Author: Cristian Ciocaltea Date: Tue Feb 4 14:40:06 2025 +0200 drm/rockchip: vop2: Improve display modes handling on RK3588 HDMI0 [ Upstream commit 2c1268e7aad0819f38e56134bbc2095fd95fde1b ] The RK3588 specific implementation is currently quite limited in terms of handling the full range of display modes supported by the connected screens, e.g. 2560x1440@75Hz, 2048x1152@60Hz, 1024x768@60Hz are just a few of them. Additionally, it doesn't cope well with non-integer refresh rates like 59.94, 29.97, 23.98, etc. Make use of HDMI0 PHY PLL as a more accurate DCLK source to handle all display modes up to 4K@60Hz. Tested-by: FUKAUMI Naoki Signed-off-by: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20250204-vop2-hdmi0-disp-modes-v3-3-d71c6a196e58@collabora.com Signed-off-by: Sasha Levin commit 91c53b8cd81cea29eb3eb8fa9bca602edafce0c7 Author: Depeng Shao Date: Mon Jan 13 10:01:27 2025 +0530 media: qcom: camss: Add default case in vfe_src_pad_code [ Upstream commit 2f4204bb00b32eca3391a468d3b37e87feb96fa9 ] Add a default case in vfe_src_pad_code to get rid of a compile warning if a new hw enum is added. Signed-off-by: Depeng Shao Reviewed-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 85e0e03303390af936323053e9b5a6a16f830e39 Author: Depeng Shao Date: Mon Jan 13 10:01:28 2025 +0530 media: qcom: camss: csid: Only add TPG v4l2 ctrl if TPG hardware is available [ Upstream commit 2f1361f862a68063f37362f1beb400e78e289581 ] There is no CSID TPG on some SoCs, so the v4l2 ctrl in CSID driver shouldn't be registered. Checking the supported TPG modes to indicate if the TPG hardware exists or not and only registering v4l2 ctrl for CSID only when the TPG hardware is present. Signed-off-by: Depeng Shao Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1d15319323d84f1653ac7ea8d3684a225dbbf787 Author: Jaegeuk Kim Date: Thu Jan 30 05:06:07 2025 +0000 f2fs: introduce f2fs_base_attr for global sysfs entries [ Upstream commit 21925ede449e038ed6f9efdfe0e79f15bddc34bc ] In /sys/fs/f2fs/features, there's no f2fs_sb_info, so let's avoid to get the pointer. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 77818483460b5f95295ab6a3d8b36e4dcf6d4576 Author: Andrey Vatoropin Date: Tue Feb 4 09:54:08 2025 +0000 hwmon: (xgene-hwmon) use appropriate type for the latency value [ Upstream commit 8df0f002827e18632dcd986f7546c1abf1953a6f ] The expression PCC_NUM_RETRIES * pcc_chan->latency is currently being evaluated using 32-bit arithmetic. Since a value of type 'u64' is used to store the eventual result, and this result is later sent to the function usecs_to_jiffies with input parameter unsigned int, the current data type is too wide to store the value of ctx->usecs_lat. Change the data type of "usecs_lat" to a more suitable (narrower) type. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Andrey Vatoropin Link: https://lore.kernel.org/r/20250204095400.95013-1-a.vatoropin@crpt.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c4092cb06398fb571a863e59f607fc8a4de6c089 Author: Len Brown Date: Thu Feb 6 21:46:24 2025 -0600 tools/power turbostat: Clustered Uncore MHz counters should honor show/hide options [ Upstream commit 1c7c7388e6c31f46b26a884d80b45efbad8237b2 ] The clustered uncore frequency counters, UMHz*.* should honor the --show and --hide options. All non-specified counters should be implicityly hidden. But when --show was used, UMHz*.* showed up anyway: $ sudo turbostat -q -S --show Busy% Busy%  UMHz0.0  UMHz1.0  UMHz2.0  UMHz3.0  UMHz4.0 Indeed, there was no string that can be used to explicitly show or hide clustered uncore counters. Even through they are dynamically probed and added, group the clustered UMHz*.* counters with the legacy built-in-counter "UncMHz" for show/hide. turbostat --show Busy% does not show UMHz*.*. turbostat --show UncMHz shows either UncMHz or UMHz*.*, if present turbostat --hide UncMHz hides either UncMHz or UMHz*.*, if present Reported-by: Artem Bityutskiy Signed-off-by: Len Brown Tested-by: Artem Bityutskiy Signed-off-by: Sasha Levin commit 247b420fea7988dca0e1287f1d4eb1e0b16b20f1 Author: Jakub Kicinski Date: Thu Feb 6 14:56:37 2025 -0800 net: page_pool: avoid false positive warning if NAPI was never added [ Upstream commit c1e00bc4be06cacee6307cedb9b55bbaddb5044d ] We expect NAPI to be in disabled state when page pool is torn down. But it is also legal if the NAPI is completely uninitialized. Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250206225638.1387810-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b063f36a929a39e17fb5622e10cecf2c5d94c6c3 Author: Jordan Crouse Date: Wed Jan 22 22:26:12 2025 +0000 clk: qcom: camcc-sm8250: Use clk_rcg2_shared_ops for some RCGs [ Upstream commit 52b10b591f83dc6d9a1d6c2dc89433470a787ecd ] Update some RCGs on the sm8250 camera clock controller to use clk_rcg2_shared_ops. The shared_ops ensure the RCGs get parked to the XO during clock disable to prevent the clocks from locking up when the GDSC is enabled. These mirror similar fixes for other controllers such as commit e5c359f70e4b ("clk: qcom: camcc: Update the clock ops for the SC7180"). Signed-off-by: Jordan Crouse Reviewed-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20250122222612.32351-1-jorcrous@amazon.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2368794c0cf4126d144230cf296a644848b36f32 Author: Ping-Ke Shih Date: Mon Feb 3 15:29:08 2025 +0800 wifi: rtw89: call power_on ahead before selecting firmware [ Upstream commit d078f5857a00c06fa0ddee26d3cb722e938e1688 ] Driver selects firmware by hardware version, which normally can be read from registers before selecting firmware. However, certain chips such as RTL8851B, it needs to read hardware version from efuse while doing power_on, but do power_on after selecting firmware in current flow. To resolve this flow problem, move power_on out from rtw89_mac_partial_init(), and call rtw89_mac_pwr_on() separately at proper places to have expected flow. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250203072911.47313-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 01edf9255f33dac1bee463c84a3dcb445a4d517c Author: Ping-Ke Shih Date: Mon Feb 3 15:29:10 2025 +0800 wifi: rtw89: fw: validate multi-firmware header before accessing [ Upstream commit 1f0efffd597893404aea5c3d4f1bdaa1c61d4434 ] A firmeware file contains multi-firmware with a header to represent contents. The mfw_hdr->fw_nr is to define number of firmware in file. +-----+-------+------+---------+--------------+ | sig | fw_nr | rsvd | version | reserved | +---------------------------------------------+ -- fw 0 | cv | type | mp | rsvd | shift | size | rsvd | \ +---------------------------------------------+ | fw 1 | cv | type | mp | rsvd | shift | size | rsvd | | mfw_hdr->fw_nr +---------------------------------------------+ | fw N-1 | ... | / +=============================================+ -- | fw 0 content | | (pointed by fw0 shift/size) | +=============================================+ To avoid Coverity warning, validate header is in range of firmware size, and also validate the range of actual firmware content is in range. Addresses-Coverity-ID: 1494046 ("Untrusted loop bound") Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250203072911.47313-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit f4c99c7b710b1e232ddad7448b22cc962af779ae Author: Ping-Ke Shih Date: Mon Feb 3 15:29:11 2025 +0800 wifi: rtw89: fw: validate multi-firmware header before getting its size [ Upstream commit 2b8bdc5237014cc61784b3676cbaca5325959f3d ] To access firmware elements appended after multi-firmware, add its size as offset to get start address of firmware elements. +-----+-------+------+---------+--------------+ -- | sig | fw_nr | rsvd | version | reserved | \ +---------------------------------------------+ | fw 0 | cv | type | mp | rsvd | shift | size | rsvd | | +---------------------------------------------+ | fw 1 | cv | type | mp | rsvd | shift | size | rsvd | | +---------------------------------------------+ | fw N-1 | ... | | +=============================================+ | mfw size | fw 0 content | | +=============================================+ | | fw 1 content | | +=============================================+ | | ... | | +=============================================+ | | fw N -1 content | | +=============================================+ --/ | fw element TLV X | +=============================================+ | fw element TLV Y | +=============================================+ | fw element TLV Z | +=============================================+ To avoid Coverity warning when getting mfw size, validate it header ahead. Addresses-Coverity-ID: 1544385 ("Untrusted array index read") Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250203072911.47313-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit 2eb2cfca35801ad7274102cfc2e2ef4bb4b72abb Author: Ching-Te Ku Date: Wed Feb 5 09:32:31 2025 +0800 wifi: rtw89: coex: Assign value over than 0 to avoid firmware timer hang [ Upstream commit 2e4c4717b3f6f019c71af984564b6e4d0ae8d0bd ] If the slot duration is 0, the firmware timer will trigger timer hang at the timer initializing state in a low rate due to hardware algorithm. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250205013233.10945-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 50f78100b9393c5a96fd44a7f3f28712ceb34e8d Author: Bitterblue Smith Date: Tue Feb 4 20:36:56 2025 +0200 wifi: rtw88: Fix __rtw_download_firmware() for RTL8814AU [ Upstream commit 8425f5c8f04dbcf11ade78f984a494fc0b90e7a0 ] Don't call ltecoex_read_reg() and ltecoex_reg_write() when the ltecoex_addr member of struct rtw_chip_info is NULL. The RTL8814AU doesn't have this feature. Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/55b5641f-094e-4f94-9f79-ac053733f2cf@gmail.com Signed-off-by: Sasha Levin commit 1c564864438b2af596c0715df6b0084df2fce9c8 Author: Bitterblue Smith Date: Tue Feb 4 20:37:36 2025 +0200 wifi: rtw88: Fix download_firmware_validate() for RTL8814AU [ Upstream commit 9e8243025cc06abc975c876dffda052073207ab3 ] After the firmware is uploaded, download_firmware_validate() checks some bits in REG_MCUFW_CTRL to see if everything went okay. The RTL8814AU power on sequence sets bits 13 and 12 to 2, which this function does not expect, so it thinks the firmware upload failed. Make download_firmware_validate() ignore bits 13 and 12. Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/049d2887-22fc-47b7-9e59-62627cb525f8@gmail.com Signed-off-by: Sasha Levin commit 2a25d61107c6e32600e11697b91ab75feb11d0ac Author: Zhang Yi Date: Fri Dec 20 09:16:28 2024 +0800 ext4: remove writable userspace mappings before truncating page cache [ Upstream commit 17207d0bb209e8b40f27d7f3f96e82a78af0bf2c ] When zeroing a range of folios on the filesystem which block size is less than the page size, the file's mapped blocks within one page will be marked as unwritten, we should remove writable userspace mappings to ensure that ext4_page_mkwrite() can be called during subsequent write access to these partial folios. Otherwise, data written by subsequent mmap writes may not be saved to disk. $mkfs.ext4 -b 1024 /dev/vdb $mount /dev/vdb /mnt $xfs_io -t -f -c "pwrite -S 0x58 0 4096" -c "mmap -rw 0 4096" \ -c "mwrite -S 0x5a 2048 2048" -c "fzero 2048 2048" \ -c "mwrite -S 0x59 2048 2048" -c "close" /mnt/foo $od -Ax -t x1z /mnt/foo 000000 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 * 000800 59 59 59 59 59 59 59 59 59 59 59 59 59 59 59 59 * 001000 $umount /mnt && mount /dev/vdb /mnt $od -Ax -t x1z /mnt/foo 000000 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 * 000800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 001000 Fix this by introducing ext4_truncate_page_cache_block_range() to remove writable userspace mappings when truncating a partial folio range. Additionally, move the journal data mode-specific handlers and truncate_pagecache_range() into this function, allowing it to serve as a common helper that correctly manages the page cache in preparation for block range manipulations. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20241220011637.1157197-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 73733c2fdb378ea072e05b7c67189fe4e2cd8603 Author: Zhang Yi Date: Fri Dec 20 09:16:30 2024 +0800 ext4: don't write back data before punch hole in nojournal mode [ Upstream commit 43d0105e2c7523cc6b14cad65e2044e829c0a07a ] There is no need to write back all data before punching a hole in non-journaled mode since it will be dropped soon after removing space. Therefore, the call to filemap_write_and_wait_range() can be eliminated. Besides, similar to ext4_zero_range(), we must address the case of partially punched folios when block size < page size. It is essential to remove writable userspace mappings to ensure that the folio can be faulted again during subsequent mmap write access. In journaled mode, we need to write dirty pages out before discarding page cache in case of crash before committing the freeing data transaction, which could expose old, stale data, even if synchronization has been performed. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20241220011637.1157197-4-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 39255ab2edfb01707cade37b05a20328c9873e01 Author: Marek Vasut Date: Mon Jan 20 12:36:53 2025 +0100 leds: trigger: netdev: Configure LED blink interval for HW offload [ Upstream commit c629c972b310af41e9e072febb6dae9a299edde6 ] In case a PHY LED implements .blink_set callback to set LED blink interval, call it even if .hw_control is already set, as that LED blink interval likely controls the blink rate of that HW offloaded LED. For PHY LEDs, that can be their activity blinking interval. The software blinking is not affected by this change. With this change, the LED interval setting looks something like this: $ echo netdev > /sys/class/leds/led:green:lan/trigger $ echo 1 > /sys/class/leds/led:green:lan/brightness $ echo 250 > /sys/class/leds/led:green:lan/interval Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20250120113740.91807-1-marex@denx.de Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 16ddd67bb5579a14cb91c9692a11b1fd0349be45 Author: Kees Cook Date: Thu Feb 6 11:16:59 2025 -0800 pstore: Change kmsg_bytes storage size to u32 [ Upstream commit 5674609535bafa834ab014d90d9bbe8e89223a0b ] The types around kmsg_bytes were inconsistent. The global was unsigned long, the argument to pstore_set_kmsg_bytes() was int, and the filesystem option was u32. Given other internal limits, there's not much sense in making a single pstore record larger than INT_MAX and it can't be negative, so use u32 everywhere. Additionally, use READ/WRITE_ONCE and a local variable in pstore_dump() to avoid kmsg_bytes changing during a dump. Link: https://lore.kernel.org/r/20250206191655.work.798-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 556f53a8ec3749f5f6d00b1f520996773e596744 Author: David Lechner Date: Fri Feb 7 14:09:07 2025 -0600 iio: adc: ad7944: don't use storagebits for sizing [ Upstream commit 503d20ed8cf7c7b40ec0bd94f53c490c1d91c31b ] Replace use of storagebits with realbits for determining the number of bytes needed for SPI transfers. When adding SPI offload support, storagebits will always be 32 rather than 16 for 16-bit 16-bit chips so we can no longer rely on storagebits being the correct size expected by the SPI framework (it always uses 4 bytes for > 16-bit xfers and 2 bytes for > 8-bit xfers). Instead, derive the correct size from realbits since it will always be correct even when SPI offloading is used. Reviewed-by: Jonathan Cameron Reviewed-vy: Nuno Sa Signed-off-by: David Lechner Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-10-e48a489be48c@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7fea5a914001a64ac149331cf0d423b490a59f61 Author: Aleksander Jan Bajkowski Date: Thu Feb 6 23:40:33 2025 +0100 r8152: add vendor/device ID pair for Dell Alienware AW1022z [ Upstream commit 848b09d53d923b4caee5491f57a5c5b22d81febc ] The Dell AW1022z is an RTL8156B based 2.5G Ethernet controller. Add the vendor and product ID values to the driver. This makes Ethernet work with the adapter. Signed-off-by: Aleksander Jan Bajkowski Link: https://patch.msgid.link/20250206224033.980115-1-olek2@wp.pl Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f2911868a73342ec950e67a0d19adc933bdd45e Author: Kuniyuki Iwashima Date: Fri Feb 7 16:24:58 2025 +0900 ip: fib_rules: Fetch net from fib_rule in fib[46]_rule_configure(). [ Upstream commit 5a1ccffd30a08f5a2428cd5fbb3ab03e8eb6c66d ] The following patch will not set skb->sk from VRF path. Let's fetch net from fib_rule->fr_net instead of sock_net(skb->sk) in fib[46]_rule_configure(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Tested-by: Ido Schimmel Link: https://patch.msgid.link/20250207072502.87775-5-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f9ab6efdee1ff6dc8b1d3e2c6063e9c1e8f8e55b Author: Athira Rajeev Date: Tue Jan 21 18:46:20 2025 +0530 arch/powerpc/perf: Check the instruction type before creating sample with perf_mem_data_src [ Upstream commit 2ffb26afa64261139e608bf087a0c1fe24d76d4d ] perf mem report aborts as below sometimes (during some corner case) in powerpc: # ./perf mem report 1>out *** stack smashing detected ***: terminated Aborted (core dumped) The backtrace is as below: __pthread_kill_implementation () raise () abort () __libc_message __fortify_fail __stack_chk_fail hist_entry.lvl_snprintf __sort__hpp_entry __hist_entry__snprintf hists.fprintf cmd_report cmd_mem Snippet of code which triggers the issue from tools/perf/util/sort.c static int hist_entry__lvl_snprintf(struct hist_entry *he, char *bf, size_t size, unsigned int width) { char out[64]; perf_mem__lvl_scnprintf(out, sizeof(out), he->mem_info); return repsep_snprintf(bf, size, "%-*s", width, out); } The value of "out" is filled from perf_mem_data_src value. Debugging this further showed that for some corner cases, the value of "data_src" was pointing to wrong value. This resulted in bigger size of string and causing stack check fail. The perf mem data source values are captured in the sample via isa207_get_mem_data_src function. The initial check is to fetch the type of sampled instruction. If the type of instruction is not valid (not a load/store instruction), the function returns. Since 'commit e16fd7f2cb1a ("perf: Use sample_flags for data_src")', data_src field is not initialized by the perf_sample_data_init() function. If the PMU driver doesn't set the data_src value to zero if type is not valid, this will result in uninitailised value for data_src. The uninitailised value of data_src resulted in stack check fail followed by abort for "perf mem report". When requesting for data source information in the sample, the instruction type is expected to be load or store instruction. In ISA v3.0, due to hardware limitation, there are corner cases where the instruction type other than load or store is observed. In ISA v3.0 and before values "0" and "7" are considered reserved. In ISA v3.1, value "7" has been used to indicate "larx/stcx". Drop the sample if instruction type has reserved values for this field with a ISA version check. Initialize data_src to zero in isa207_get_mem_data_src if the instruction type is not load/store. Reported-by: Disha Goel Signed-off-by: Athira Rajeev Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250121131621.39054-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit c2e02e2b21591b6f31d5cad4afde04b7e01d4e7b Author: Gaurav Batra Date: Wed Jan 8 10:48:14 2025 -0600 powerpc/pseries/iommu: create DDW for devices with DMA mask less than 64-bits [ Upstream commit 67dfc11982f7e3c37f0977e74671da2391b29181 ] Starting with PAPR level 2.13, platform supports placing PHB in limited address mode. Devices that support DMA masks less that 64-bit but greater than 32-bits are placed in limited address mode. In this mode, the starting DMA address returned by the DDW is 4GB. When the device driver calls dma_supported, with mask less then 64-bit, the PowerPC IOMMU driver places PHB in the Limited Addressing Mode before creating DDW. Signed-off-by: Gaurav Batra Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250108164814.73250-1-gbatra@linux.ibm.com Signed-off-by: Sasha Levin commit 9aeaf1956e75a1a3c0355b1f82c972a29444f56a Author: Gaurav Batra Date: Thu Jan 30 12:38:54 2025 -0600 powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory [ Upstream commit 6aa989ab2bd0d37540c812b4270006ff794662e7 ] iommu_mem_notifier() is invoked when RAM is dynamically added/removed. This notifier call is responsible to add/remove TCEs from the Dynamic DMA Window (DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM and not for persistent memory (pmemory). For DMA buffers in pmemory, TCEs are dynamically mapped when the device driver instructs to do so. The issue is 'daxctl' command is capable of adding pmemory as "System RAM" after LPAR boot. The command to do so is - daxctl reconfigure-device --mode=system-ram dax0.0 --force This will dynamically add pmemory range to LPAR RAM eventually invoking iommu_mem_notifier(). The address range of pmemory is way beyond the Max RAM that the LPAR can have. Which means, this range is beyond the DDW created for the device, at device initialization time. As a result when TCEs are pre-mapped for the pmemory range, by iommu_mem_notifier(), PHYP HCALL returns H_PARAMETER. This failed the command, daxctl, to add pmemory as RAM. The solution is to not pre-map TCEs for pmemory. Signed-off-by: Gaurav Batra Tested-by: Donet Tom Reviewed-by: Donet Tom Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250130183854.92258-1-gbatra@linux.ibm.com Signed-off-by: Sasha Levin commit 701118e6f621f1379add73f9546f4e7f21d0da7d Author: Csókás, Bence Date: Fri Feb 7 13:12:55 2025 +0100 net: fec: Refactor MAC reset to function [ Upstream commit 67800d296191d0a9bde0a7776f99ca1ddfa0fc26 ] The core is reset both in `fec_restart()` (called on link-up) and `fec_stop()` (going to sleep, driver remove etc.). These two functions had their separate implementations, which was at first only a register write and a `udelay()` (and the accompanying block comment). However, since then we got soft-reset (MAC disable) and Wake-on-LAN support, which meant that these implementations diverged, often causing bugs. For instance, as of now, `fec_stop()` does not check for `FEC_QUIRK_NO_HARD_RESET`, meaning the MII/RMII mode is cleared on eg. a PM power-down event; and `fec_restart()` missed the refactor renaming the "magic" constant `1` to `FEC_ECR_RESET`. To harmonize current implementations, and eliminate this source of potential future bugs, refactor implementation to a common function. Reviewed-by: Michal Swiatkowski Reviewed-by: Jacob Keller Reviewed-by: Simon Horman Signed-off-by: Csókás, Bence Link: https://patch.msgid.link/20250207121255.161146-2-csokas.bence@prolan.hu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 641ad8d64a08c458a6c0ebd62fe196ab571d388c Author: Emmanuel Grumbach Date: Wed Feb 5 11:39:20 2025 +0200 wifi: mac80211: set ieee80211_prep_tx_info::link_id upon Auth Rx [ Upstream commit 8c60179b64434894eac1ffab7396bac131bc8b6e ] This will be used by the low level driver. Note that link_id will be 0 in case of a non-MLO authentication. Also fix a call-site of mgd_prepare_tx() where the link_id was not populated. Update the documentation to reflect the current state ieee80211_prep_tx_info::link_id is also available in mgd_complete_tx(). Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205110958.6a590f189ce5.I1fc5c0da26b143f5b07191eb592f01f7083d55ae@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8315b79220d2d757134133e2f35a3bac39a17445 Author: Johannes Berg Date: Wed Feb 5 11:39:21 2025 +0200 wifi: mac80211: remove misplaced drv_mgd_complete_tx() call [ Upstream commit f4995cdc4d02d0abc8e9fcccad5c71ce676c1e3f ] In the original commit 15fae3410f1d ("mac80211: notify driver on mgd TX completion") I evidently made a mistake and placed the call in the "associated" if, rather than the "assoc_data". Later I noticed the missing call and placed it in commit c042600c17d8 ("wifi: mac80211: adding missing drv_mgd_complete_tx() call"), but didn't remove the wrong one. Remove it now. Signed-off-by: Johannes Berg Reviewed-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205110958.6ed954179bbf.Id8ef8835b7e6da3bf913c76f77d201017dc8a3c9@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 26e384fafda89293032d95c7fd0fe3b3a1836bd6 Author: Johannes Berg Date: Wed Feb 5 11:39:22 2025 +0200 wifi: mac80211: don't unconditionally call drv_mgd_complete_tx() [ Upstream commit 1798271b3604b902d45033ec569f2bf77e94ecc2 ] We might not have called drv_mgd_prepare_tx(), so only call drv_mgd_complete_tx() under the same conditions. Signed-off-by: Johannes Berg Reviewed-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205110958.e091fc39a351.Ie6a3cdca070612a0aa4b3c6914ab9ed602d1f456@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8e1800f1db7eb3230cc5f0828807c11bdf2809d9 Author: Miri Korenblit Date: Wed Feb 5 14:55:35 2025 +0200 wifi: iwlwifi: don't warn during reprobe [ Upstream commit 696cca64308dc641d0bbe4aa2c09dd9752aa288d ] During reprobe, the sw state is being destroyd, and so is the connection. When the peer STA is being removed, the opmode sends a command to flush the TXQs of the STA and uses iwl_trans_wait_txq_empty. This one warns if the FW is not alive, but it really shouldn't if there is a FW error - and return silently instead, just like we do when sending a hcmd. Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20250205145347.76425b10e5a0.I3bf0de2eb090a8b94c4e36d93dd91df61fadb808@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 15d8ceef9289f2018702a9ac273164c8ef75a06c Author: Johannes Berg Date: Wed Feb 5 14:55:46 2025 +0200 wifi: iwlwifi: use correct IMR dump variable [ Upstream commit 21e4d29ac0def546d57bacebe4a51cbed1209b03 ] We shouldn't dump the reg_data here which dumps the last entry again, it should use the imr_reg_data. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250205145347.3313b18667d1.Iaa9ab66b1d397912a573525e060d39ea01b29d19@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4d8fd111e0f553025bbaa9b683ac141992637b46 Author: Matthieu Baerts (NGI0) Date: Fri Feb 7 14:59:20 2025 +0100 mptcp: pm: userspace: flags: clearer msg if no remote addr [ Upstream commit 58b21309f97b08b6b9814d1ee1419249eba9ef08 ] Since its introduction in commit 892f396c8e68 ("mptcp: netlink: issue MP_PRIO signals from userspace PMs"), it was mandatory to specify the remote address, because of the 'if (rem->addr.family == AF_UNSPEC)' check done later one. In theory, this attribute can be optional, but it sounds better to be precise to avoid sending the MP_PRIO on the wrong subflow, e.g. if there are multiple subflows attached to the same local ID. This can be relaxed later on if there is a need to act on multiple subflows with one command. For the moment, the check to see if attr_rem is NULL can be removed, because mptcp_pm_parse_entry() will do this check as well, no need to do that differently here. Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6a0997d78ffa367ce5077269b603551c7ba4f08c Author: P Praneesh Date: Thu Feb 6 07:08:51 2025 +0530 wifi: ath12k: fix the ampdu id fetch in the HAL_RX_MPDU_START TLV [ Upstream commit dff4f278ee1ef12d822b7ed2a1048d27037209bb ] Currently, ampdu id is update with peer id mask which is incorrect. Therefore, update the ampdu id with PPDU id mask value. Also move the ampdu_id field inside the user stats since it is a user id based statistics. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Karthikeyan Periyasamy Link: https://patch.msgid.link/20250206013854.174765-7-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 06daedb4439bb5a79c0dc13109a330ecf7fa5ce7 Author: Leon Romanovsky Date: Wed Feb 5 20:27:49 2025 +0200 xfrm: prevent high SEQ input in non-ESN mode [ Upstream commit e3aa43a50a6455831e3c32dabc7ece38d9cd9d05 ] In non-ESN mode, the SEQ numbers are limited to 32 bits and seq_hi/oseq_hi are not used. So make sure that user gets proper error message, in case such assignment occurred. Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit bbd6dc1fb6c56267ad1d58810d92287fcd5b0058 Author: Stefan Wahren Date: Sat Feb 1 13:50:46 2025 +0100 drm/v3d: Add clock handling [ Upstream commit 4dd40b5f9c3d89b67af0dbe059cf4a51aac6bf06 ] Since the initial commit 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") the struct v3d_dev reserved a pointer for an optional V3D clock. But there wasn't any code, which fetched it. So add the missing clock handling before accessing any V3D registers. Signed-off-by: Stefan Wahren Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Link: https://patchwork.freedesktop.org/patch/msgid/20250201125046.33030-1-wahrenst@gmx.net Signed-off-by: Sasha Levin commit e5a69d1696323176e06ea494abd9acbed2f7b3b2 Author: William Tu Date: Sun Feb 9 12:17:07 2025 +0200 net/mlx5e: reduce the max log mpwrq sz for ECPF and reps [ Upstream commit e1d68ea58c7e9ebacd9ad7a99b25a3578fa62182 ] For the ECPF and representors, reduce the max MPWRQ size from 256KB (18) to 128KB (17). This prepares the later patch for saving representor memory. With Striding RQ, there is a minimum of 4 MPWQEs. So with 128KB of max MPWRQ size, the minimal memory is 4 * 128KB = 512KB. When creating page pool, consider 1500 mtu, the minimal page pool size will be 512KB/4KB = 128 pages = 256 rx ring entries (2 entries per page). Before this patch, setting RX ringsize (ethtool -G rx) to 256 causes driver to allocate page pool size more than it needs due to max MPWRQ is 256KB (18). Ex: 4 * 256KB = 1MB, 1MB/4KB = 256 pages, but actually 128 pages is good enough. Reducing the max MPWRQ to 128KB fixes the limitation. Signed-off-by: William Tu Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250209101716.112774-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74d153d8ec150e2227dd0ca3cf3e512e3401bc0e Author: William Tu Date: Sun Feb 9 12:17:08 2025 +0200 net/mlx5e: reduce rep rxq depth to 256 for ECPF [ Upstream commit b9cc8f9d700867aaa77aedddfea85e53d5e5d584 ] By experiments, a single queue representor netdev consumes kernel memory around 2.8MB, and 1.8MB out of the 2.8MB is due to page pool for the RXQ. Scaling to a thousand representors consumes 2.8GB, which becomes a memory pressure issue for embedded devices such as BlueField-2 16GB / BlueField-3 32GB memory. Since representor netdevs mostly handles miss traffic, and ideally, most of the traffic will be offloaded, reduce the default non-uplink rep netdev's RXQ default depth from 1024 to 256 if mdev is ecpf eswitch manager. This saves around 1MB of memory per regular RQ, (1024 - 256) * 2KB, allocated from page pool. With rxq depth of 256, the netlink page pool tool reports $./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \ --dump page-pool-get {'id': 277, 'ifindex': 9, 'inflight': 128, 'inflight-mem': 786432, 'napi-id': 775}] This is due to mtu 1500 + headroom consumes half pages, so 256 rxq entries consumes around 128 pages (thus create a page pool with size 128), shown above at inflight. Note that each netdev has multiple types of RQs, including Regular RQ, XSK, PTP, Drop, Trap RQ. Since non-uplink representor only supports regular rq, this patch only changes the regular RQ's default depth. Signed-off-by: William Tu Reviewed-by: Bodong Wang Reviewed-by: Saeed Mahameed Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250209101716.112774-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit af94d4f46c09a52ecf70a8fb58186cfd16b334d9 Author: William Tu Date: Sun Feb 9 12:17:09 2025 +0200 net/mlx5e: set the tx_queue_len for pfifo_fast [ Upstream commit a38cc5706fb9f7dc4ee3a443f61de13ce1e410ed ] By default, the mq netdev creates a pfifo_fast qdisc. On a system with 16 core, the pfifo_fast with 3 bands consumes 16 * 3 * 8 (size of pointer) * 1024 (default tx queue len) = 393KB. The patch sets the tx qlen to representor default value, 128 (1< Reviewed-by: Daniel Jurgens Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250209101716.112774-9-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3a845ebc8f9848cc270727792175b23d98e7a5c Author: Alexei Lazar Date: Sun Feb 9 12:17:15 2025 +0200 net/mlx5: Extend Ethtool loopback selftest to support non-linear SKB [ Upstream commit 95b9606b15bb3ce1198d28d2393dd0e1f0a5f3e9 ] Current loopback test validation ignores non-linear SKB case in the SKB access, which can lead to failures in scenarios such as when HW GRO is enabled. Linearize the SKB so both cases will be handled. Signed-off-by: Alexei Lazar Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20250209101716.112774-15-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a94ccac4930da16baab1b6c5703779ef25e61e2 Author: Alexei Lazar Date: Sun Feb 9 12:17:16 2025 +0200 net/mlx5: XDP, Enable TX side XDP multi-buffer support [ Upstream commit 1a9304859b3a4119579524c293b902a8927180f3 ] In XDP scenarios, fragmented packets can occur if the MTU is larger than the page size, even when the packet size fits within the linear part. If XDP multi-buffer support is disabled, the fragmented part won't be handled in the TX flow, leading to packet drops. Since XDP multi-buffer support is always available, this commit removes the conditional check for enabling it. This ensures that XDP multi-buffer support is always enabled, regardless of the `is_xdp_mb` parameter, and guarantees the handling of fragmented packets in such scenarios. Signed-off-by: Alexei Lazar Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20250209101716.112774-16-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4df87dae1444203080fb03bebcb63035694e418 Author: Chaohai Chen Date: Fri Jan 24 16:55:42 2025 +0800 scsi: target: spc: Fix loop traversal in spc_rsoc_get_descr() [ Upstream commit 04ad06e41d1c74cc323b20a7bd023c47bd0e0c38 ] Stop traversing after finding the appropriate descriptor. Signed-off-by: Chaohai Chen Link: https://lore.kernel.org/r/20250124085542.109088-1-wdhh66@163.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9acae6e987058dadd7000aa18da9967e97fe6ad9 Author: Alex Deucher Date: Tue Dec 17 09:25:18 2024 -0500 drm/amd/display/dm: drop hw_support check in amdgpu_dm_i2c_xfer() [ Upstream commit 33da70bd1e115d7d73f45fb1c09f5ecc448f3f13 ] DC supports SW i2c as well. Drop the check. Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f5e9d0d206cbd8a064eba6996ab0bdaff12a2853 Author: Shiwu Zhang Date: Tue Nov 19 15:58:39 2024 +0800 drm/amdgpu: enlarge the VBIOS binary size limit [ Upstream commit 667b96134c9e206aebe40985650bf478935cbe04 ] Some chips have a larger VBIOS file so raise the size limit to support the flashing tool. Signed-off-by: Shiwu Zhang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7ef18e2ffdc12e7d63f14c9e289c1f5697f48405 Author: Lijo Lazar Date: Wed Jan 1 14:23:31 2025 +0530 drm/amdgpu: Use active umc info from discovery [ Upstream commit f7a594e40517fa2ab25d5ca10e7b6a158f529fb5 ] There could be configs where some UMC instances are harvested. This information is obtained through discovery data and populated in umc.active_mask. Avoid reassigning this as AID mask, instead use the mask directly while iterating through umc instances. This is to avoid accesses to harvested UMC instances. v2: fix warning (Alex) Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1bb46b5433a8a830d4ee085e7cbe2f16df71c9a3 Author: Dillon Varone Date: Wed Jan 8 15:25:41 2025 -0500 drm/amd/display: Populate register address for dentist for dcn401 [ Upstream commit 5f0d1ef6f16e150ee46cc00b8d233d9d271fe39e ] [WHY&HOW] Address was not previously populated which can result in incorrect clock frequencies being read on boot. Reviewed-by: Alvin Lee Signed-off-by: Dillon Varone Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit af3d57ea9ec7407de75e7f63bbdd5bc445c4b3b7 Author: Austin Zheng Date: Tue Jan 7 17:49:36 2025 -0500 drm/amd/display: Use Nominal vBlank If Provided Instead Of Capping It [ Upstream commit 41df56b1fc24cc36fffb10e437385b3a49fbb5e2 ] [Why/How] vBlank used to determine the max vStartup is based on the smallest between the vblank provided by the timing and vblank in ip_caps. Extra vblank time is not considered if the vblank provided by the timing ends up being higher than what's defined by the ip_caps Use 1 less than the vblank size in case the timing is interlaced so vstartup will always be less than vblank_nom. Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e55c5704b12eeea27e212bfab8f7e51ad3e8ac1f Author: Joshua Aberback Date: Wed Jan 8 12:03:23 2025 -0500 drm/amd/display: Increase block_sequence array size [ Upstream commit 3a7810c212bcf2f722671dadf4b23ff70a7d23ee ] [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash. [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient. Reviewed-by: Alvin Lee Signed-off-by: Joshua Aberback Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 17e40a52a1492c6c0affc33676f8381391750094 Author: Tom Chung Date: Mon Jan 13 14:22:31 2025 +0800 drm/amd/display: Initial psr_version with correct setting [ Upstream commit d8c782cac5007e68e7484d420168f12d3490def6 ] [Why & How] The initial setting for psr_version is not correct while create a virtual link. The default psr_version should be DC_PSR_VERSION_UNSUPPORTED. Reviewed-by: Roman Li Signed-off-by: Tom Chung Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 563adeeeb0ffa3caeed83750d374387137e0c301 Author: George Shen Date: Fri Jan 10 11:35:46 2025 -0500 drm/amd/display: Update CR AUX RD interval interpretation [ Upstream commit 6a7fde433231c18164c117592d3e18ced648ad58 ] [Why] DP spec updated to have the CR AUX RD interval match the EQ AUX RD interval interpretation of DPCD 0000Eh/0220Eh for 8b/10b non-LTTPR mode and LTTPR transparent mode cases. [How] Update interpretation of DPCD 0000Eh/0220Eh for CR AUX RD interval during 8b/10b link training. Reviewed-by: Michael Strauss Reviewed-by: Wenjing Liu Signed-off-by: George Shen Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 47bfc7a02704f5789fea366c857ace535ba247b5 Author: Brandon Syu Date: Tue Jan 21 13:29:51 2025 +0800 Revert "drm/amd/display: Exit idle optimizations before attempt to access PHY" [ Upstream commit be704e5ef4bd66dee9bb3f876964327e3a247d31 ] This reverts commit de612738e9771bd66aeb20044486c457c512f684. Reason to revert: screen flashes or gray screen appeared half of the screen after resume from S4/S5. Reviewed-by: Charlene Liu Signed-off-by: Brandon Syu Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 45068cc170ebf2c0c7b1626841c361a62f66fb77 Author: Martin Tsai Date: Mon Jan 20 11:21:46 2025 +0800 drm/amd/display: Support multiple options during psr entry. [ Upstream commit 3a5fa55455db6a11248a25f24570c365f9246144 ] [WHY] Some panels may not handle idle pattern properly during PSR entry. [HOW] Add a condition to allow multiple options on power down sequence during PSR1 entry. Reviewed-by: Anthony Koo Signed-off-by: Martin Tsai Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4f4cb81def4332163ae00d6fa6d42b1aeba29a54 Author: Asad Kamal Date: Thu Dec 19 19:16:37 2024 +0800 drm/amd/pm: Skip P2S load for SMU v13.0.12 [ Upstream commit 1fb85819d629676f1d53f40c3fffa25a33a881e4 ] Skip P2S table load for SMU v13.0.12 Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a25d045ebfbcea87e8cd4e960b7554c3fd7c1f00 Author: Jiang Liu Date: Fri Feb 7 14:28:49 2025 +0800 drm/amdgpu: reset psp->cmd to NULL after releasing the buffer [ Upstream commit e92f3f94cad24154fd3baae30c6dfb918492278d ] Reset psp->cmd to NULL after releasing the buffer in function psp_sw_fini(). Reviewed-by: Lijo Lazar Signed-off-by: Jiang Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ed2039d840a12b35e17f9cb1f4a594330c573a0c Author: Ilya Bakoulin Date: Tue Jan 28 13:14:54 2025 -0500 drm/amd/display: Don't try AUX transactions on disconnected link [ Upstream commit e8bffa52e0253cfd689813a620e64521256bc712 ] [Why] Setting link DPMS off in response to HPD disconnect creates AUX transactions on a link that is supposed to be disconnected. This can cause issues in some cases when the sink re-asserts HPD and expects source to re-enable the link. [How] Avoid AUX transactions on disconnected link. Reviewed-by: Wenjing Liu Signed-off-by: Ilya Bakoulin Signed-off-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a8726bee7046dac60399c2ee88e85584b4c9bc7d Author: Charlene Liu Date: Mon Jan 13 11:57:54 2025 -0500 drm/amd/display: pass calculated dram_speed_mts to dml2 [ Upstream commit b40d022ec06ade9f6c809091dc188422a0f0946d ] [why] currently dml2 is using a hard coded 16 to convert memclk to dram_speed_mts. for apu, this depends on wck_ratio. change to pass the already calculated dram_speed_mts from fpu to dml2. v2: use existing calculation of dram_speed_mts for now to avoid regression Signed-off-by: Charlene Liu Signed-off-by: Aurabindo Pillai Reviewed-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 452807a863018375186790bed955382b6bd5829e Author: Harish Kasiviswanathan Date: Tue Feb 4 17:57:47 2025 -0500 drm/amdgpu: Set snoop bit for SDMA for MI series [ Upstream commit 3394b1f76d3f8adf695ceed350a5dae49003eb37 ] SDMA writes has to probe invalidate RW lines. Set snoop bit in mmhub for this to happen. v2: Missed a few mmhub_v9_4. Added now. v3: Calculate hub offset once since it doesn't change inside the loop Modified function names based on review comments. Signed-off-by: Harish Kasiviswanathan Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5ca70518bc23d2db5cb46d2b9cae40eee4312e8a Author: Eric Huang Date: Tue Jan 28 15:48:26 2025 -0500 drm/amdkfd: fix missing L2 cache info in topology [ Upstream commit 5ffd56822a7159917306d99f18fd15dfd7288f20 ] In some ASICs L2 cache info may miss in kfd topology, because the first bitmap may be empty, that means the first cu may be inactive, so to find the first active cu will solve the issue. v2: Only find the first active cu in the first xcc Signed-off-by: Eric Huang Acked-by: Alex Deucher Acked-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 365d302ac763dbd045c9dfd591d8087e8436bcde Author: Alex Deucher Date: Fri Feb 7 09:39:24 2025 -0500 drm/amdgpu/mes11: fix set_hw_resources_1 calculation [ Upstream commit 1350dd3691b5f757a948e5b9895d62c422baeb90 ] It's GPU page size not CPU page size. In most cases they are the same, but not always. This can lead to overallocation on systems with larger pages. Cc: Srinivasan Shanmugam Cc: Christian König Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 11c7fa11fa0763a1cff17a5de81511437c9cffd7 Author: Huacai Chen Date: Mon Feb 10 21:43:28 2025 +0800 net: stmmac: dwmac-loongson: Set correct {tx,rx}_fifo_size [ Upstream commit 8dbf0c7556454b52af91bae305ca71500c31495c ] Now for dwmac-loongson {tx,rx}_fifo_size are uninitialised, which means zero. This means dwmac-loongson doesn't support changing MTU because in stmmac_change_mtu() it requires the fifo size be no less than MTU. Thus, set the correct tx_fifo_size and rx_fifo_size for it (16KB multiplied by queue counts). Here {tx,rx}_fifo_size is initialised with the initial value (also the maximum value) of {tx,rx}_queues_to_use. So it will keep as 16KB if we don't change the queue count, and will be larger than 16KB if we change (decrease) the queue count. However stmmac_change_mtu() still work well with current logic (MTU cannot be larger than 16KB for stmmac). Note: the Fixes tag picked here is the oldest commit and key commit of the dwmac-loongson series "stmmac: Add Loongson platform support". Acked-by: Yanteng Si Reviewed-by: Simon Horman Signed-off-by: Chong Qiao Signed-off-by: Huacai Chen Link: https://patch.msgid.link/20250210134328.2755328-1-chenhuacai@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97dba4472e4840bae874561542c7f41ed3eb22db Author: Bard Liao Date: Wed Feb 5 15:42:31 2025 +0800 soundwire: cadence_master: set frame shape and divider based on actual clk freq [ Upstream commit e738d77f78b3ac085dfb51be414e93464abba7ec ] Frame shape and curr_dr_freq could be updated by sdw_compute_bus_params(). Peripherals will set curr_dr_freq as their frequency. Managers should do the same. Then update frame shape according to the actual bus frequency. Signed-off-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20250205074232.87537-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c043867b654ec9c709cb3697a7ebbaf0ae2e0cc6 Author: Vijendar Mukunda Date: Fri Feb 7 12:28:36 2025 +0530 soundwire: amd: change the soundwire wake enable/disable sequence [ Upstream commit dcc48a73eae7f791b1a6856ea1bcc4079282c88d ] During runtime suspend scenario, SoundWire wake should be enabled and during system level suspend scenario SoundWire wake should be disabled. Implement the SoundWire wake enable/disable sequence as per design flow for SoundWire poweroff mode. Signed-off-by: Vijendar Mukunda Link: https://lore.kernel.org/r/20250207065841.4718-2-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 164c9f5edf2aea7314b06bc50b607973ce461551 Author: André Draszik Date: Fri Dec 6 16:31:04 2024 +0000 phy: exynos5-usbdrd: fix EDS distribution tuning (gs101) [ Upstream commit 21860f340ba76ee042e5431ff92537f89bc11476 ] This code's intention is to configure lane0 and lane2 tunings, but for lane2 there is a typo and it ends up tuning something else. Fix the typo, as it doesn't appear to make sense to apply different tunings for lane0 vs lane2. The same typo appears to exist in the bootloader, hence we restore the original value in the typo'd registers as well. This can be removed once / if the bootloader is updated. Note that this is incorrect in the downstream driver as well - the values had been copied from there. Reviewed-by: Peter Griffin Tested-by: Peter Griffin Signed-off-by: André Draszik Tested-by: Will McVicker Link: https://lore.kernel.org/r/20241206-gs101-phy-lanes-orientation-phy-v4-4-f5961268b149@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ef31dc41cf67ba0363c990ece8ccaa23fd16f7e6 Author: Dmitry Baryshkov Date: Sun Feb 9 14:31:45 2025 +0200 phy: core: don't require set_mode() callback for phy_get_mode() to work [ Upstream commit d58c04e305afbaa9dda7969151f06c4efe2c98b0 ] As reported by Damon Ding, the phy_get_mode() call doesn't work as expected unless the PHY driver has a .set_mode() call. This prompts PHY drivers to have empty stubs for .set_mode() for the sake of being able to get the mode. Make .set_mode() callback truly optional and update PHY's mode even if it there is none. Cc: Damon Ding Link: https://lore.kernel.org/r/96f8310f-93f1-4bcb-8637-137e1159ff83@rock-chips.com Tested-by: Damon Ding Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250209-phy-fix-set-moe-v2-1-76e248503856@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit afb512502f2d74b2b4ee76fe0b698ece3a1dc789 Author: Damon Ding Date: Wed Feb 5 18:51:54 2025 +0800 phy: phy-rockchip-samsung-hdptx: Swap the definitions of LCPLL_REF and ROPLL_REF [ Upstream commit 2947c8065e9efdd3b6434d2817dc8896234a3fc0 ] According to the datasheet, setting the dig_clk_sel bit of CMN_REG(0097) to 1'b1 selects LCPLL as the reference clock, while setting it to 1'b0 selects the ROPLL. Signed-off-by: Damon Ding Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250205105157.580060-2-damon.ding@rock-chips.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a507a213e82ca368b18a31f14a2f4813bc14771b Author: Claudiu Beznea Date: Wed Feb 5 12:01:16 2025 +0200 pinctrl: renesas: rzg2l: Add suspend/resume support for pull up/down [ Upstream commit b2bd65fbb617353e3c46ba5206b3b030fa0f260c ] The Renesas RZ/G3S supports a power-saving mode where power to most of the SoC components is lost, including the PIN controller. Save and restore the pull-up/pull-down register contents to ensure the functionality is preserved after a suspend/resume cycle. Signed-off-by: Claudiu Beznea Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250205100116.2032765-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 5de11f82cbfd17be1f3d36a15d54396206eccf11 Author: Claudiu Beznea Date: Fri Feb 7 13:33:13 2025 +0200 serial: sh-sci: Update the suspend/resume support [ Upstream commit 22a6984c5b5df8eab864d7f3e8b94d5a554d31ab ] The Renesas RZ/G3S supports a power saving mode where power to most of the SoC components is turned off. When returning from this power saving mode, SoC components need to be re-configured. The SCIFs on the Renesas RZ/G3S need to be re-configured as well when returning from this power saving mode. The sh-sci code already configures the SCIF clocks, power domain and registers by calling uart_resume_port() in sci_resume(). On suspend path the SCIF UART ports are suspended accordingly (by calling uart_suspend_port() in sci_suspend()). The only missing setting is the reset signal. For this assert/de-assert the reset signal on driver suspend/resume. In case the no_console_suspend is specified by the user, the registers need to be saved on suspend path and restore on resume path. To do this the sci_console_save()/sci_console_restore() functions were added. There is no need to cache/restore the status or FIFO registers. Only the control registers. The registers that will be saved/restored on suspend/resume are specified by the struct sci_suspend_regs data structure. Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20250207113313.545432-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6e31b0182de596f73baf298cae12e04fcf6498b Author: zihan zhou <15645113830zzh@gmail.com> Date: Sat Feb 8 15:53:23 2025 +0800 sched: Reduce the default slice to avoid tasks getting an extra tick [ Upstream commit 2ae891b826958b60919ea21c727f77bcd6ffcc2c ] The old default value for slice is 0.75 msec * (1 + ilog(ncpus)) which means that we have a default slice of: 0.75 for 1 cpu 1.50 up to 3 cpus 2.25 up to 7 cpus 3.00 for 8 cpus and above. For HZ=250 and HZ=100, because of the tick accuracy, the runtime of tasks is far higher than their slice. For HZ=1000 with 8 cpus or more, the accuracy of tick is already satisfactory, but there is still an issue that tasks will get an extra tick because the tick often arrives a little faster than expected. In this case, the task can only wait until the next tick to consider that it has reached its deadline, and will run 1ms longer. vruntime + sysctl_sched_base_slice = deadline |-----------|-----------|-----------|-----------| 1ms 1ms 1ms 1ms ^ ^ ^ ^ tick1 tick2 tick3 tick4(nearly 4ms) There are two reasons for tick error: clockevent precision and the CONFIG_IRQ_TIME_ACCOUNTING/CONFIG_PARAVIRT_TIME_ACCOUNTING. with CONFIG_IRQ_TIME_ACCOUNTING every tick will be less than 1ms, but even without it, because of clockevent precision, tick still often less than 1ms. In order to make scheduling more precise, we changed 0.75 to 0.70, Using 0.70 instead of 0.75 should not change much for other configs and would fix this issue: 0.70 for 1 cpu 1.40 up to 3 cpus 2.10 up to 7 cpus 2.8 for 8 cpus and above. This does not guarantee that tasks can run the slice time accurately every time, but occasionally running an extra tick has little impact. Signed-off-by: zihan zhou <15645113830zzh@gmail.com> Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20250208075322.13139-1-15645113830zzh@gmail.com Signed-off-by: Sasha Levin commit 9c5f85b72fa6d285c91e7d867b4c3643a6952efb Author: Peter Zijlstra Date: Fri Feb 7 13:15:36 2025 +0100 x86/traps: Cleanup and robustify decode_bug() [ Upstream commit c20ad96c9a8f0aeaf4e4057730a22de2657ad0c2 ] Notably, don't attempt to decode an immediate when MOD == 3. Additionally have it return the instruction length, such that WARN like bugs can more reliably skip to the correct instruction. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sami Tolvanen Link: https://lore.kernel.org/r/20250207122546.721120726@infradead.org Signed-off-by: Sasha Levin commit eb6fd16b4fc4feb370c68ec17b59f6078f276a51 Author: Peter Zijlstra Date: Thu Feb 13 12:45:47 2025 +0100 x86/ibt: Handle FineIBT in handle_cfi_failure() [ Upstream commit 882b86fd4e0d49bf91148dbadcdbece19ded40e6 ] Sami reminded me that FineIBT failure does not hook into the regular CFI failure case, and as such CFI_PERMISSIVE does not work. Reported-by: Sami Tolvanen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sami Tolvanen Link: https://lkml.kernel.org/r/20250214092619.GB21726@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit b870651021223b127efe51b11772b0078a7a49fe Author: Shuicheng Lin Date: Thu Feb 13 23:03:22 2025 +0000 drm/xe/debugfs: Add missing xe_pm_runtime_put in wedge_mode_set [ Upstream commit b31e668d3111b100d16fd7db8db335328ce8c6d5 ] xe_pm_runtime_put is missed in the failure path. Cc: Rodrigo Vivi Signed-off-by: Shuicheng Lin Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20250213230322.1180621-1-shuicheng.lin@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit cf126a14584e5f49647824d4b266567359f0e297 Author: Xin Wang Date: Fri Feb 14 06:36:15 2025 +0800 drm/xe/debugfs: fixed the return value of wedged_mode_set [ Upstream commit 6884d2051011f4db9e2f0b85709c79a8ced13bd6 ] It is generally expected that the write() function should return a positive value indicating the number of bytes written or a negative error code if an error occurs. Returning 0 is unusual and can lead to unexpected behavior. When the user program writes the same value to wedged_mode twice in a row, a lockup will occur, because the value expected to be returned by the write() function inside the program should be equal to the actual written value instead of 0. To reproduce the issue: echo 1 > /sys/kernel/debug/dri/0/wedged_mode echo 1 > /sys/kernel/debug/dri/0/wedged_mode <- lockup here Signed-off-by: Xin Wang Cc: Rodrigo Vivi Cc: Fei Yang Cc: Shuicheng Lin Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20250213223615.2327367-1-x.wang@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 6469a2b1140d0be363b72dfafe0fc0bbc9504493 Author: Krzysztof Kozlowski Date: Wed Feb 12 21:01:35 2025 +0100 clk: qcom: clk-alpha-pll: Do not use random stack value for recalc rate [ Upstream commit 7a243e1b814a02ab40793026ef64223155d86395 ] If regmap_read() fails, random stack value was used in calculating new frequency in recalc_rate() callbacks. Such failure is really not expected as these are all MMIO reads, however code should be here correct and bail out. This also avoids possible warning on uninitialized value. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250212-b4-clk-qcom-clean-v3-1-499f37444f5d@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 328a2ec198e70f2a3eae206a2718468602a178db Author: Karl Chan Date: Tue Oct 8 00:34:12 2024 +0800 clk: qcom: ipq5018: allow it to be bulid on arm32 [ Upstream commit 5d02941c83997b58e8fc15390290c7c6975acaff ] There are some ipq5018 based device's firmware only can able to boot arm32 but the clock driver dont allow it to be compiled on arm32. Therefore allow GCC for IPQ5018 to be selected when building ARM32 kernel Signed-off-by: Karl Chan Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20241007163414.32458-4-exxxxkc@getgoogleoff.me [bjorn: Updated commit message, per Dmitry's suggestion] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 01d28e67f567bcb0aa0533a4b805370131ffc4f4 Author: Lucas De Marchi Date: Thu Feb 13 11:29:00 2025 -0800 drm/xe: Fix xe_tile_init_noalloc() error propagation [ Upstream commit 0bcf41171c64234e79eb3552d00f0aad8a47e8d3 ] Propagate the error to the caller so initialization properly stops if sysfs creation fails. Reviewed-by: Francois Dugast Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20250213192909.996148-4-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 884d64e8e4dc6d4f1b0f69c31e4b4eadaf735648 Author: Lucas De Marchi Date: Thu Feb 13 11:29:01 2025 -0800 drm/xe: Stop ignoring errors from xe_ttm_stolen_mgr_init() [ Upstream commit ff57025c358603555f1e0ae0d50282a460433594 ] Make sure to differentiate normal behavior, e.g. there's no stolen, from allocation errors or failure to initialize lower layers. Reviewed-by: Francois Dugast Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20250213192909.996148-5-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 50c5bbb45c7dfea22c566c75ca62e306848f18ba Author: Kees Cook Date: Mon Feb 10 09:45:05 2025 -0800 net/mlx4_core: Avoid impossible mlx4_db_alloc() order value [ Upstream commit 4a6f18f28627e121bd1f74b5fcc9f945d6dbeb1e ] GCC can see that the value range for "order" is capped, but this leads it to consider that it might be negative, leading to a false positive warning (with GCC 15 with -Warray-bounds -fdiagnostics-details): ../drivers/net/ethernet/mellanox/mlx4/alloc.c:691:47: error: array subscript -1 is below array bounds of 'long unsigned int *[2]' [-Werror=array-bounds=] 691 | i = find_first_bit(pgdir->bits[o], MLX4_DB_PER_PAGE >> o); | ~~~~~~~~~~~^~~ 'mlx4_alloc_db_from_pgdir': events 1-2 691 | i = find_first_bit(pgdir->bits[o], MLX4_DB_PER_PAGE >> o); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (2) out of array bounds here | (1) when the condition is evaluated to true In file included from ../drivers/net/ethernet/mellanox/mlx4/mlx4.h:53, from ../drivers/net/ethernet/mellanox/mlx4/alloc.c:42: ../include/linux/mlx4/device.h:664:33: note: while referencing 'bits' 664 | unsigned long *bits[2]; | ^~~~ Switch the argument to unsigned int, which removes the compiler needing to consider negative values. Signed-off-by: Kees Cook Link: https://patch.msgid.link/20250210174504.work.075-kees@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 69689d1138c85f5a46485289d0691bdc95c91e00 Author: Sakari Ailus Date: Mon Dec 16 10:48:49 2024 +0200 media: v4l: Memset argument to 0 before calling get_mbus_config pad op [ Upstream commit 91d6a99acfa5ce9f95ede775074b80f7193bd717 ] Memset the config argument to get_mbus_config V4L2 sub-device pad operation to zero before calling the operation. This ensures the callers don't need to bother with it nor the implementations need to set all fields that may not be relevant to them. Signed-off-by: Sakari Ailus Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9a981079097bee6a0583877798de0b240717bdde Author: David Plowman Date: Tue Feb 4 12:34:36 2025 +0530 media: i2c: imx219: Correct the minimum vblanking value [ Upstream commit e3b82d49bf676f3c873e642038765eac32ab6d39 ] The datasheet for this sensor documents the minimum vblanking as being 32 lines. It does fix some problems with occasional black lines at the bottom of images (tested on Raspberry Pi). Signed-off-by: David Plowman Reviewed-by: Jacopo Mondi Reviewed-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 12aeff4944dc6263d1e5b00001097ff40aed9180 Author: Brendan Jackman Date: Fri Jan 24 11:01:42 2025 +0000 kunit: tool: Use qboot on QEMU x86_64 [ Upstream commit 08fafac4c9f289a9d9a22d838921e4b3eb22c664 ] As noted in [0], SeaBIOS (QEMU default) makes a mess of the terminal, qboot does not. It turns out this is actually useful with kunit.py, since the user is exposed to this issue if they set --raw_output=all. qboot is also faster than SeaBIOS, but it's is marginal for this usecase. [0] https://lore.kernel.org/all/CA+i-1C0wYb-gZ8Mwh3WSVpbk-LF-Uo+njVbASJPe1WXDURoV7A@mail.gmail.com/ Both SeaBIOS and qboot are x86-specific. Link: https://lore.kernel.org/r/20250124-kunit-qboot-v1-1-815e4d4c6f7c@google.com Signed-off-by: Brendan Jackman Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 8f5ce688c8318e4a68ccb235495a183286a49b79 Author: Konstantin Andreev Date: Fri Jan 17 02:40:33 2025 +0300 smack: Revert "smackfs: Added check catlen" [ Upstream commit c7fb50cecff9cad19fdac5b37337eae4e42b94c7 ] This reverts commit ccfd889acb06eab10b98deb4b5eef0ec74157ea0 The indicated commit * does not describe the problem that change tries to solve * has programming issues * introduces a bug: forever clears NETLBL_SECATTR_MLS_CAT in (struct smack_known *)skp->smk_netlabel.flags Reverting the commit to reapproach original problem Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 316f2911fb11aedee07d047feb958bfb7416159e Author: Konstantin Andreev Date: Fri Jan 17 02:40:34 2025 +0300 smack: recognize ipv4 CIPSO w/o categories [ Upstream commit a158a937d864d0034fea14913c1f09c6d5f574b8 ] If SMACK label has CIPSO representation w/o categories, e.g.: | # cat /smack/cipso2 | foo 10 | @ 250/2 | ... then SMACK does not recognize such CIPSO in input ipv4 packets and substitues '*' label instead. Audit records may look like | lsm=SMACK fn=smack_socket_sock_rcv_skb action=denied | subject="*" object="_" requested=w pid=0 comm="swapper/1" ... This happens in two steps: 1) security/smack/smackfs.c`smk_set_cipso does not clear NETLBL_SECATTR_MLS_CAT from (struct smack_known *)skp->smk_netlabel.flags on assigning CIPSO w/o categories: | rcu_assign_pointer(skp->smk_netlabel.attr.mls.cat, ncats.attr.mls.cat); | skp->smk_netlabel.attr.mls.lvl = ncats.attr.mls.lvl; 2) security/smack/smack_lsm.c`smack_from_secattr can not match skp->smk_netlabel with input packet's struct netlbl_lsm_secattr *sap because sap->flags have not NETLBL_SECATTR_MLS_CAT (what is correct) but skp->smk_netlabel.flags have (what is incorrect): | if ((sap->flags & NETLBL_SECATTR_MLS_CAT) == 0) { | if ((skp->smk_netlabel.flags & | NETLBL_SECATTR_MLS_CAT) == 0) | found = 1; | break; | } This commit sets/clears NETLBL_SECATTR_MLS_CAT in skp->smk_netlabel.flags according to the presense of CIPSO categories. The update of smk_netlabel is not atomic, so input packets processing still may be incorrect during short time while update proceeds. Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 5b1b4cb46d9514bec053b392d2266f00e0d6ee19 Author: Valentin Caron Date: Thu Jan 16 18:00:09 2025 +0100 pinctrl: devicetree: do not goto err when probing hogs in pinctrl_dt_to_map [ Upstream commit c98868e816209e568c9d72023ba0bc1e4d96e611 ] Cross case in pinctrl framework make impossible to an hogged pin and another, not hogged, used within the same device-tree node. For example with this simplified device-tree : &pinctrl { pinctrl_pin_1: pinctrl-pin-1 { pins = "dummy-pinctrl-pin"; }; }; &rtc { pinctrl-names = "default" pinctrl-0 = <&pinctrl_pin_1 &rtc_pin_1> rtc_pin_1: rtc-pin-1 { pins = "dummy-rtc-pin"; }; }; "pinctrl_pin_1" configuration is never set. This produces this path in the code: really_probe() pinctrl_bind_pins() | devm_pinctrl_get() | pinctrl_get() | create_pinctrl() | pinctrl_dt_to_map() | // Hog pin create an abort for all pins of the node | ret = dt_to_map_one_config() | | /* Do not defer probing of hogs (circular loop) */ | | if (np_pctldev == p->dev->of_node) | | return -ENODEV; | if (ret) | goto err | call_driver_probe() stm32_rtc_probe() pinctrl_enable() pinctrl_claim_hogs() create_pinctrl() for_each_maps(maps_node, i, map) // Not hog pin is skipped if (pctldev && strcmp(dev_name(pctldev->dev), map->ctrl_dev_name)) continue; At the first call of create_pinctrl() the hogged pin produces an abort to avoid a defer of hogged pins. All other pin configurations are trashed. At the second call, create_pinctrl is now called with pctldev parameter to get hogs, but in this context only hogs are set. And other pins are skipped. To handle this, do not produce an abort in the first call of create_pinctrl(). Classic pin configuration will be set in pinctrl_bind_pins() context. And the hogged pin configuration will be set in pinctrl_claim_hogs() context. Signed-off-by: Valentin Caron Link: https://lore.kernel.org/20250116170009.2075544-1-valentin.caron@foss.st.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c4260bf83b4296a94b272291eac66dc52cc0cc46 Author: Kuninori Morimoto Date: Wed Feb 12 02:24:38 2025 +0000 ASoC: soc-dai: check return value at snd_soc_dai_set_tdm_slot() [ Upstream commit 7f1186a8d738661b941b298fd6d1d5725ed71428 ] snd_soc_dai_set_tdm_slot() calls .xlate_tdm_slot_mask() or snd_soc_xlate_tdm_slot_mask(), but didn't check its return value. Let's check it. This patch might break existing driver. In such case, let's makes each func to void instead of int. Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87o6z7yk61.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2ea042779621d5f79e1049114f7be62e414722b1 Author: Hector Martin Date: Sat Feb 8 01:03:24 2025 +0000 ASoC: tas2764: Power up/down amp on mute ops [ Upstream commit 1c3b5f37409682184669457a5bdf761268eafbe5 ] The ASoC convention is that clocks are removed after codec mute, and power up/down is more about top level power management. For these chips, the "mute" state still expects a TDM clock, and yanking the clock in this state will trigger clock errors. So, do the full shutdown<->mute<->active transition on the mute operation, so the amp is in software shutdown by the time the clocks are removed. This fixes TDM clock errors when streams are stopped. Signed-off-by: Hector Martin Signed-off-by: Mark Brown Link: https://patch.msgid.link/20250208-asoc-tas2764-v1-1-dbab892a69b5@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 409c12ce79b33c15ba668b883f17d14d948d22e4 Author: Hector Martin Date: Sat Feb 8 01:03:26 2025 +0000 ASoC: tas2764: Mark SW_RESET as volatile [ Upstream commit f37f1748564ac51d32f7588bd7bfc99913ccab8e ] Since the bit is self-clearing. Signed-off-by: Hector Martin Signed-off-by: Mark Brown Link: https://patch.msgid.link/20250208-asoc-tas2764-v1-3-dbab892a69b5@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8d8083881ecbb8112317e8e407ae617fa07c8077 Author: Hector Martin Date: Sat Feb 8 01:03:27 2025 +0000 ASoC: tas2764: Add reg defaults for TAS2764_INT_CLK_CFG [ Upstream commit d64c4c3d1c578f98d70db1c5e2535b47adce9d07 ] Signed-off-by: Hector Martin Signed-off-by: Mark Brown Link: https://patch.msgid.link/20250208-asoc-tas2764-v1-4-dbab892a69b5@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 000dd6e3441fcb0094ad7960d6b9bd7c570f13ea Author: Martin Povišer Date: Sat Feb 8 00:57:22 2025 +0000 ASoC: ops: Enforce platform maximum on initial value [ Upstream commit 783db6851c1821d8b983ffb12b99c279ff64f2ee ] Lower the volume if it is violating the platform maximum at its initial value (i.e. at the time of the 'snd_soc_limit_volume' call). Signed-off-by: Martin Povišer [Cherry picked from the Asahi kernel with fixups -- broonie] Signed-off-by: Mark Brown Link: https://patch.msgid.link/20250208-asoc-volume-limit-v1-1-b98fcf4cdbad@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 83ea9472389530b78d1a5daae267e7e75e4533dd Author: Siva Durga Prasad Paladugu Date: Fri Feb 7 11:19:51 2025 +0530 firmware: xilinx: Dont send linux address to get fpga config get status [ Upstream commit 5abc174016052caff1bcf4cedb159bd388411e98 ] Fpga get config status just returns status through ret_payload and there is no need to allocate local buf and send its address through SMC args. Moreover, the address that is being passed till now is linux virtual address and is incorrect. Corresponding modification has been done in the firmware to avoid using the address sent by linux. Signed-off-by: Siva Durga Prasad Paladugu Signed-off-by: Nava kishore Manne Link: https://lore.kernel.org/r/20250207054951.1650534-1-nava.kishore.manne@amd.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit e1c4bb3774421fdcd941bbb6a6a20d86be555d26 Author: Sudeep Holla Date: Mon Feb 17 15:38:48 2025 +0000 firmware: arm_ffa: Handle the presence of host partition in the partition info [ Upstream commit 2f622a8b0722d332a2a149794a3add47bc9bdcf3 ] Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as part of the response to PARTITION_INFO_GET from the firmware. However, there are few platforms that prefer to present the same in the list of partitions. It is not manadatory but not restricted as well. So handle the same by making sure to check the presence of the host VM ID in the XArray partition information maintained/managed in the driver before attempting to add it. Tested-by: Viresh Kumar Message-Id: <20250217-ffa_updates-v3-7-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 3a3fab1be5a0c177d9d45bb3aa8d2897604fa601 Author: Sudeep Holla Date: Mon Feb 17 15:38:53 2025 +0000 firmware: arm_ffa: Reject higher major version as incompatible [ Upstream commit efff6a7f16b34fd902f342b58bd8bafc2d6f2fd1 ] When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"), we only addressed firmware versions that have higher minor versions compared to the driver version which is should be considered compatible unless the firmware returns NOT_SUPPORTED. However, if the firmware reports higher major version than the driver supported, we need to reject it. If the firmware can work in a compatible mode with the driver requested version, it must return the same major version as requested. Tested-by: Viresh Kumar Message-Id: <20250217-ffa_updates-v3-12-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 587386c56fb886577bac3e201ef57be43a6720a6 Author: Shahar Shitrit Date: Thu Feb 13 11:46:38 2025 +0200 net/mlx5: Apply rate-limiting to high temperature warning [ Upstream commit 9dd3d5d258aceb37bdf09c8b91fa448f58ea81f0 ] Wrap the high temperature warning in a temperature event with a call to net_ratelimit() to prevent flooding the kernel log with repeated warning messages when temperature exceeds the threshold multiple times within a short duration. Signed-off-by: Shahar Shitrit Signed-off-by: Tariq Toukan Reviewed-by: Mateusz Polchlopek Link: https://patch.msgid.link/20250213094641.226501-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c4e1ce22b9ab964a09bc5532c9fae9b4738d36b8 Author: Shahar Shitrit Date: Thu Feb 13 11:46:40 2025 +0200 net/mlx5: Modify LSB bitmask in temperature event to include only the first bit [ Upstream commit 633f16d7e07c129a36b882c05379e01ce5bdb542 ] In the sensor_count field of the MTEWE register, bits 1-62 are supported only for unmanaged switches, not for NICs, and bit 63 is reserved for internal use. To prevent confusing output that may include set bits that are not relevant to NIC sensors, we update the bitmask to retain only the first bit, which corresponds to the sensor ASIC. Signed-off-by: Shahar Shitrit Signed-off-by: Tariq Toukan Reviewed-by: Mateusz Polchlopek Link: https://patch.msgid.link/20250213094641.226501-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3770acff3110f0fa1438b34050d359e827cba59d Author: Hans Verkuil Date: Mon Dec 9 16:00:16 2024 +0100 media: test-drivers: vivid: don't call schedule in loop [ Upstream commit e4740118b752005cbed339aec9a1d1c43620e0b9 ] Artem reported that the CPU load was 100% when capturing from vivid at low resolution with ffmpeg. This was caused by: while (time_is_after_jiffies(cur_jiffies + wait_jiffies) && !kthread_should_stop()) schedule(); If there are no other processes running that can be scheduled, then this is basically a busy-loop. Change it to wait_event_interruptible_timeout() which doesn't have that problem. Signed-off-by: Hans Verkuil Reported-by: Artem S. Tashkinov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219570 Reviewed-by: Nicolas Dufresne Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2fe6284364423d81b2f87d06da5617999e0f30cc Author: Andrew Jones Date: Mon Feb 17 14:26:47 2025 +0530 irqchip/riscv-imsic: Set irq_set_affinity() for IMSIC base [ Upstream commit 999f458c1771354371ba367dd84f55f9a62a4233 ] The IMSIC driver assigns the IMSIC domain specific imsic_irq_set_affinity() callback to the per device leaf MSI domain. That's a layering violation as it is called with the leaf domain data and not with the IMSIC domain data. This prevents moving the IMSIC driver to the common MSI library which uses the generic msi_domain_set_affinity() callback for device MSI domains. Instead of using imsic_irq_set_affinity() for leaf MSI domains, use imsic_irq_set_affinity() for the non-leaf IMSIC base domain and use irq_chip_set_affinity_parent() for leaf MSI domains. [ tglx: Massaged change log ] Signed-off-by: Andrew Jones Signed-off-by: Anup Patel Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250217085657.789309-2-apatel@ventanamicro.com Signed-off-by: Sasha Levin commit dc5f5c9d2bbc634eb144beb7d2cea950725d03c8 Author: Andy Shevchenko Date: Fri Feb 14 15:43:33 2025 +0200 hrtimers: Replace hrtimer_clock_to_base_table with switch-case [ Upstream commit 4441b976dfeff0d3579e8da3c0283300c618a553 ] Clang and GCC complain about overlapped initialisers in the hrtimer_clock_to_base_table definition. With `make W=1` and CONFIG_WERROR=y (which is default nowadays) this breaks the build: CC kernel/time/hrtimer.o kernel/time/hrtimer.c:124:21: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides] 124 | [CLOCK_REALTIME] = HRTIMER_BASE_REALTIME, kernel/time/hrtimer.c:122:27: note: previous initialization is here 122 | [0 ... MAX_CLOCKS - 1] = HRTIMER_MAX_CLOCK_BASES, (and similar for CLOCK_MONOTONIC, CLOCK_BOOTTIME, and CLOCK_TAI). hrtimer_clockid_to_base(), which uses the table, is only used in __hrtimer_init(), which is not a hotpath. Therefore replace the table lookup with a switch case in hrtimer_clockid_to_base() to avoid this warning. Signed-off-by: Andy Shevchenko Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250214134424.3367619-1-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin commit 7f131fda2654e880700d6826b362e6862ac9ba8a Author: Petr Machata Date: Fri Feb 14 17:18:21 2025 +0100 vxlan: Join / leave MC group after remote changes [ Upstream commit d42d543368343c0449a4e433b5f02e063a86209c ] When a vxlan netdevice is brought up, if its default remote is a multicast address, the device joins the indicated group. Therefore when the multicast remote address changes, the device should leave the current group and subscribe to the new one. Similarly when the interface used for endpoint communication is changed in a situation when multicast remote is configured. This is currently not done. Both vxlan_igmp_join() and vxlan_igmp_leave() can however fail. So it is possible that with such fix, the netdevice will end up in an inconsistent situation where the old group is not joined anymore, but joining the new group fails. Should we join the new group first, and leave the old one second, we might end up in the opposite situation, where both groups are joined. Undoing any of this during rollback is going to be similarly problematic. One solution would be to just forbid the change when the netdevice is up. However in vnifilter mode, changing the group address is allowed, and these problems are simply ignored (see vxlan_vni_update_group()): # ip link add name br up type bridge vlan_filtering 1 # ip link add vx1 up master br type vxlan external vnifilter local 192.0.2.1 dev lo dstport 4789 # bridge vni add dev vx1 vni 200 group 224.0.0.1 # tcpdump -i lo & # bridge vni add dev vx1 vni 200 group 224.0.0.2 18:55:46.523438 IP 0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s) 18:55:46.943447 IP 0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s) # bridge vni dev vni group/remote vx1 200 224.0.0.2 Having two different modes of operation for conceptually the same interface is silly, so in this patch, just do what the vnifilter code does and deal with the errors by crossing fingers real hard. The vnifilter code leaves old before joining new, and in case of join / leave failures does not roll back the configuration changes that have already been applied, but bails out of joining if it could not leave. Do the same here: leave before join, apply changes unconditionally and do not attempt to join if we couldn't leave. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1fb8106316a218256faf60b37d81134b6e7c798a Author: Xiaofei Tan Date: Wed Feb 12 14:34:08 2025 +0800 ACPI: HED: Always initialize before evged [ Upstream commit cccf6ee090c8c133072d5d5b52ae25f3bc907a16 ] When the HED driver is built-in, it initializes after evged because they both are at the same initcall level, so the initialization ordering depends on the Makefile order. However, this prevents RAS records coming in between the evged driver initialization and the HED driver initialization from being handled. If the number of such RAS records is above the APEI HEST error source number, the HEST resources may be exhausted, and that may affect subsequent RAS error reporting. To fix this issue, change the initcall level of HED to subsys_initcall and prevent the driver from being built as a module by changing ACPI_HED in Kconfig from "tristate" to "bool". Signed-off-by: Xiaofei Tan Link: https://patch.msgid.link/20250212063408.927666-1-tanxiaofei@huawei.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 82b54455b6b7f103cd71c7dafd07328331e4f3dd Author: Ilpo Järvinen Date: Mon Dec 16 19:56:12 2024 +0200 PCI: Fix old_size lower bound in calculate_iosize() too [ Upstream commit ff61f380de5652e723168341480cc7adf1dd6213 ] Commit 903534fa7d30 ("PCI: Fix resource double counting on remove & rescan") fixed double counting of mem resources because of old_size being applied too early. Fix a similar counting bug on the io resource side. Link: https://lore.kernel.org/r/20241216175632.4175-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xiaochun Lee Signed-off-by: Sasha Levin commit 161cc125043a24cf14b86e61e57221a820e8fb5e Author: Jakub Kicinski Date: Wed Feb 12 17:06:33 2025 -0800 eth: mlx4: don't try to complete XDP frames in netpoll [ Upstream commit 8fdeafd66edaf420ea0063a1f13442fe3470fe70 ] mlx4 doesn't support ndo_xdp_xmit / XDP_REDIRECT and wasn't using page pool until now, so it could run XDP completions in netpoll (NAPI budget == 0) just fine. Page pool has calling context requirements, make sure we don't try to call it from what is potentially HW IRQ context. Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250213010635.1354034-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46ba5757a7a4714e7d3f68cfe118208822cb3d78 Author: Eduard Zingerman Date: Sat Feb 15 03:03:52 2025 -0800 bpf: copy_verifier_state() should copy 'loop_entry' field [ Upstream commit bbbc02b7445ebfda13e4847f4f1413c6480a85a9 ] The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state. Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack(). See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix. This change has some verification performance impact for selftests: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%) And significant negative impact for sched_ext: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch 2393 3580 +1187 (+49.60%) 196 253 +57 (+29.08%) scx_qmap.bpf.o qmap_dump 233 318 +85 (+36.48%) 22 30 +8 (+36.36%) scx_qmap.bpf.o qmap_init 16367 17436 +1069 (+6.53%) 603 669 +66 (+10.95%) Note 'layered_dump' program, which now hits 1M instructions limit. This impact would be mitigated in the next patch. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250215110411.3236773-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2b129e89b8c6e261bd240f56989fc52ec5efbd87 Author: Eduard Zingerman Date: Sat Feb 15 03:03:54 2025 -0800 bpf: don't do clean_live_states when state->loop_entry->branches > 0 [ Upstream commit 9e63fdb0cbdf3268c86638a8274f4d5549a82820 ] verifier.c:is_state_visited() uses RANGE_WITHIN states comparison rules for cached states that have loop_entry with non-zero branches count (meaning that loop_entry's verification is not yet done). The RANGE_WITHIN rules in regsafe()/stacksafe() require register and stack objects types to be identical in current and old states. verifier.c:clean_live_states() replaces registers and stack spills with NOT_INIT/STACK_INVALID marks, if these registers/stack spills are not read in any child state. This means that clean_live_states() works against loop convergence logic under some conditions. See selftest in the next patch for a specific example. Mitigate this by prohibiting clean_verifier_state() when state->loop_entry->branches > 0. This undoes negative verification performance impact of the copy_verifier_state() fix from the previous patch. Below is comparison between master and current patch. selftests: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ---------------------------------- ---------------------------- --------- --------- --------------- ---------- ---------- -------------- arena_htab.bpf.o arena_htab_llvm 717 423 -294 (-41.00%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_add 1493 1822 +329 (+22.04%) 30 37 +7 (+23.33%) arena_list.bpf.o arena_list_del 309 261 -48 (-15.53%) 23 15 -8 (-34.78%) iters.bpf.o checkpoint_states_deletion 18125 22154 +4029 (+22.23%) 818 918 +100 (+12.22%) iters.bpf.o iter_nested_deeply_iters 593 367 -226 (-38.11%) 67 43 -24 (-35.82%) iters.bpf.o iter_nested_iters 813 772 -41 (-5.04%) 79 72 -7 (-8.86%) iters.bpf.o iter_subprog_check_stacksafe 155 135 -20 (-12.90%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 808 -286 (-26.14%) 88 68 -20 (-22.73%) iters.bpf.o loop_state_deps2 479 356 -123 (-25.68%) 46 35 -11 (-23.91%) iters.bpf.o triple_continue 35 31 -4 (-11.43%) 3 3 +0 (+0.00%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) mptcp_subflow.bpf.o _getsockopt_subflow 501 446 -55 (-10.98%) 25 23 -2 (-8.00%) pyperf600_iter.bpf.o on_event 12339 6379 -5960 (-48.30%) 441 286 -155 (-35.15%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 192 +79 (+69.91%) 12 21 +9 (+75.00%) sched_ext: File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) ----------------- ---------------------- --------- --------- ----------------- ---------- ---------- ---------------- bpf.bpf.o layered_dispatch 11485 9039 -2446 (-21.30%) 848 662 -186 (-21.93%) bpf.bpf.o layered_dump 7422 5022 -2400 (-32.34%) 681 298 -383 (-56.24%) bpf.bpf.o layered_enqueue 16854 13753 -3101 (-18.40%) 1611 1308 -303 (-18.81%) bpf.bpf.o layered_init 1000001 5549 -994452 (-99.45%) 84672 523 -84149 (-99.38%) bpf.bpf.o layered_runnable 3149 1899 -1250 (-39.70%) 288 151 -137 (-47.57%) bpf.bpf.o p2dq_init 2343 1936 -407 (-17.37%) 201 170 -31 (-15.42%) bpf.bpf.o refresh_layer_cpumasks 16487 1285 -15202 (-92.21%) 1770 120 -1650 (-93.22%) bpf.bpf.o rusty_select_cpu 1937 1386 -551 (-28.45%) 177 125 -52 (-29.38%) scx_central.bpf.o central_dispatch 636 600 -36 (-5.66%) 63 59 -4 (-6.35%) scx_central.bpf.o central_init 913 632 -281 (-30.78%) 48 39 -9 (-18.75%) scx_nest.bpf.o nest_init 636 601 -35 (-5.50%) 60 58 -2 (-3.33%) scx_pair.bpf.o pair_dispatch 1000001 1914 -998087 (-99.81%) 58169 142 -58027 (-99.76%) scx_qmap.bpf.o qmap_dispatch 2393 2187 -206 (-8.61%) 196 174 -22 (-11.22%) scx_qmap.bpf.o qmap_init 16367 22777 +6410 (+39.16%) 603 768 +165 (+27.36%) 'layered_init' and 'pair_dispatch' hit 1M on master, but are verified ok with this patch. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20250215110411.3236773-4-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit eaeb67bd851ce573490470b8afd21971d9db942a Author: Krzysztof Kozlowski Date: Wed Feb 12 21:23:14 2025 +0100 can: c_can: Use of_property_present() to test existence of DT property [ Upstream commit ab1bc2290fd8311d49b87c29f1eb123fcb581bee ] of_property_read_bool() should be used only on boolean properties. Cc: Rob Herring Signed-off-by: Krzysztof Kozlowski Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250212-syscon-phandle-args-can-v2-3-ac9a1253396b@linaro.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit a89326d35bf6fe7b0498311c88a06e35c743434c Author: Ahmad Fatoum Date: Tue Feb 18 20:18:32 2025 +0100 pmdomain: imx: gpcv2: use proper helper for property detection [ Upstream commit 6568cb40e73163fa25e2779f7234b169b2e1a32e ] Starting with commit c141ecc3cecd7 ("of: Warn when of_property_read_bool() is used on non-boolean properties"), probing the gpcv2 device on i.MX8M SoCs leads to warnings when LOCKDEP is enabled. Fix this by checking property presence with of_property_present as intended. Signed-off-by: Ahmad Fatoum Link: https://lore.kernel.org/r/20250218-gpcv2-of-property-present-v1-1-3bb1a9789654@pengutronix.de Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 3ccfdd5b337429079325f456e499706313e251e1 Author: Michael Margolin Date: Mon Feb 17 14:16:23 2025 +0000 RDMA/core: Fix best page size finding when it can cross SG entries [ Upstream commit 486055f5e09df959ad4e3aa4ee75b5c91ddeec2e ] A single scatter-gather entry is limited by a 32 bits "length" field that is practically 4GB - PAGE_SIZE. This means that even when the memory is physically contiguous, we might need more than one entry to represent it. Additionally when using dmabuf, the sg_table might be originated outside the subsystem and optimized for other needs. For instance an SGT of 16GB GPU continuous memory might look like this: (a real life example) dma_address 34401400000, length fffff000 dma_address 345013ff000, length fffff000 dma_address 346013fe000, length fffff000 dma_address 347013fd000, length fffff000 dma_address 348013fc000, length 4000 Since ib_umem_find_best_pgsz works within SG entries, in the above case we will result with the worst possible 4KB page size. Fix this by taking into consideration only the alignment of addresses of real discontinuity points rather than treating SG entries as such, and adjust the page iterator to correctly handle cross SG entry pages. There is currently an assumption that drivers do not ask for pages bigger than maximal DMA size supported by their devices. Reviewed-by: Firas Jahjah Reviewed-by: Yonatan Nachum Signed-off-by: Michael Margolin Link: https://patch.msgid.link/20250217141623.12428-1-mrgolin@amazon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e6a46719a2369eb5186d4f7e6c0478720ca1ec3d Author: Alexis Lothoré Date: Mon Feb 17 07:21:53 2025 +0100 serial: mctrl_gpio: split disable_ms into sync and no_sync APIs [ Upstream commit 1bd2aad57da95f7f2d2bb52f7ad15c0f4993a685 ] The following splat has been observed on a SAMA5D27 platform using atmel_serial: BUG: sleeping function called from invalid context at kernel/irq/manage.c:738 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0 preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<00000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7bec softirqs last enabled at (0): [] copy_process+0x1ca0/0x7bec softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74 Hardware name: Atmel SAMA5 Workqueue: hci0 hci_power_on [bluetooth] Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28 This warning is emitted when trying to toggle, at the highest level, some flow control (with serdev_device_set_flow_control) in a device driver. At the lowest level, the atmel_serial driver is using serial_mctrl_gpio lib to enable/disable the corresponding IRQs accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to disable_irq (called in mctrl_gpio_disable_ms) being possibly called in some atomic context (some tty drivers perform modem lines configuration in regions protected by port lock). Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one and a blocking one. Replace mctrl_gpio_disable_ms calls with the relevant version depending on whether the call is protected by some port lock. Suggested-by: Jiri Slaby Signed-off-by: Alexis Lothoré Acked-by: Richard Genoud Link: https://lore.kernel.org/r/20250217-atomic_sleep_mctrl_serial_gpio-v3-1-59324b313eef@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b14e726d57f61085485f107a6203c50a09695abd Author: Harry Wentland Date: Fri Jan 31 11:57:49 2025 -0500 drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink [ Upstream commit cbf4890c6f28fb1ad733e14613fbd33c2004bced ] Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector. While dereferencing aconnector->base will "work" it's wrong and might lead to unknown bad things. Just... don't. Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cee5d56fa783ff852a23da5ce3da17fd0d450d18 Author: Leo Zeng Date: Fri Jan 31 11:46:52 2025 -0500 Revert "drm/amd/display: Request HW cursor on DCN3.2 with SubVP" [ Upstream commit 8ae6dfc0b61b170cf13832d4cfe2a0c744e621a7 ] This reverts commit 13437c91606c9232c747475e202fe3827cd53264. Reason to revert: idle power regression found in testing. Reviewed-by: Dillon Varone Signed-off-by: Leo Zeng Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 775f3afa6ade18e5d7a89af092517bd38c7183d2 Author: George Shen Date: Tue Feb 4 14:34:02 2025 -0500 drm/amd/display: Read LTTPR ALPM caps during link cap retrieval [ Upstream commit de84d580126eb2214937df755cfec5ef0901479e ] [Why] The latest DP spec requires the DP TX to read DPCD F0000h through F0009h when detecting LTTPR capabilities for the first time. [How] Update LTTPR cap retrieval to read up to F0009h (two more bytes than the previous F0007h), and store the LTTPR ALPM capabilities. Reviewed-by: Wenjing Liu Signed-off-by: George Shen Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1e826acee1165a05c119366f4e902a4a11ee2460 Author: Ilya Bakoulin Date: Wed Jan 29 14:46:27 2025 -0500 drm/amd/display: Fix BT2020 YCbCr limited/full range input [ Upstream commit 07bc2dcbcf403d47d6f305ef7f0d3d489491c5fb ] [Why] BT2020 YCbCr input is not handled properly when full range quantization is used and limited range is not supported at all. [How] - Add enums for BT2020 YCbCr limited/full range - Add limited range CSC matrix Reviewed-by: Krunoslav Kovac Signed-off-by: Ilya Bakoulin Signed-off-by: Roman Li Tested-by: Robert Mader Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2bba67f03071a83dacbcaa9569a0541cdfe8083d Author: Nicholas Kazlauskas Date: Mon Feb 3 09:49:58 2025 -0500 drm/amd/display: Guard against setting dispclk low when active [ Upstream commit 72d7a7fa1f2404fd31c84a8f808b1b37021a3a9e ] [Why] We should never apply a minimum dispclk value while in prepare_bandwidth or while displays are active. This is always an optimization for when all displays are disabled. [How] Defer dispclk optimization until safe_to_lower = true and display_count reaches 0. Since 0 has a special value in this logic (ie. no dispclk required) we also need adjust the logic that clamps it for the actual request to PMFW. Reviewed-by: Gabe Teeger Reviewed-by: Leo Chen Reviewed-by: Syed Hassan Signed-off-by: Nicholas Kazlauskas Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b02b561bf7692d8db2b7218c076aad8c32e1261c Author: Harry VanZyllDeJong Date: Fri Feb 7 13:46:53 2025 -0500 drm/amd/display: Add support for disconnected eDP streams [ Upstream commit 6571bef25fe48c642f7a69ccf7c3198b317c136a ] [Why] eDP may not be connected to the GPU on driver start causing fail enumeration. [How] Move the virtual signal type check before the eDP connector signal check. Reviewed-by: Wenjing Liu Signed-off-by: Harry VanZyllDeJong Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 94e6687ceda912d52d6e030f0079bc6a33a47f0b Author: Lijo Lazar Date: Tue Feb 18 17:43:01 2025 +0530 drm/amd/pm: Fetch current power limit from PMFW [ Upstream commit b2a9e562dfa156bd53e62ce571f3f8f65d243f14 ] On SMU v13.0.12, always query the firmware to get the current power limit as it could be updated through other means also. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 098788e118d1e8e480735242934fbc80cee645c2 Author: Anup Patel Date: Mon Feb 17 14:26:53 2025 +0530 irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector [ Upstream commit 0f67911e821c67ecfccc365a2103ce276a9a56fe ] Currently, there is only one "move" pointer in struct imsic_vector so during vector movement the old vector points to the new vector and new vector points to itself. To support forced cleanup of the old vector, add separate "move_next" and "move_prev" pointers to struct imsic_vector, where during vector movement the "move_next" pointer of the old vector points to the new vector and the "move_prev" pointer of the new vector points to the old vector. Both "move_next" and "move_prev" pointers are cleared separately by __imsic_local_sync() with a restriction that "move_prev" on the new CPU is cleared only after the old CPU has cleared "move_next". Signed-off-by: Anup Patel Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250217085657.789309-8-apatel@ventanamicro.com Signed-off-by: Sasha Levin commit d85004266a32c69fb72243983bac9818c7998b01 Author: Eddie James Date: Tue Feb 18 16:09:59 2025 -0600 eeprom: ee1004: Check chip before probing [ Upstream commit d9406677428e9234ea62bb2d2f5e996d1b777760 ] Like other eeprom drivers, check if the device is really there and functional before probing. Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20250218220959.721698-1-eajames@linux.ibm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 011a62d2d79ac5a1a14a1cc9d2f62490d25451b5 Author: Chris Morgan Date: Tue Feb 4 09:58:32 2025 -0600 mfd: axp20x: AXP717: Add AXP717_TS_PIN_CFG to writeable regs [ Upstream commit bfad07fe298bfba0c7ddab87c5b5325970203a1e ] Add AXP717_TS_PIN_CFG (register 0x50) to the table of writeable registers so that the temperature sensor can be configured by the battery driver. Signed-off-by: Chris Morgan Link: https://lore.kernel.org/r/20250204155835.161973-3-macroalpha82@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit a82c0c39967710d6232b51a78b71222e9ffec705 Author: Frank Li Date: Wed Jan 29 11:22:50 2025 -0500 i3c: master: svc: Flush FIFO before sending Dynamic Address Assignment(DAA) [ Upstream commit a892ee4cf22a50e1d6988d0464a9a421f3e5db2f ] Ensure the FIFO is empty before issuing the DAA command to prevent incorrect command data from being sent. Align with other data transfers, such as svc_i3c_master_start_xfer_locked(), which flushes the FIFO before sending a command. Signed-off-by: Frank Li Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20250129162250.3629189-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7d0c92af8d3557131da00059d34712b82922aecb Author: Arnd Bergmann Date: Wed Jan 22 07:50:26 2025 +0100 EDAC/ie31200: work around false positive build warning [ Upstream commit c29dfd661fe2f8d1b48c7f00590929c04b25bf40 ] gcc-14 produces a bogus warning in some configurations: drivers/edac/ie31200_edac.c: In function 'ie31200_probe1.isra': drivers/edac/ie31200_edac.c:412:26: error: 'dimm_info' is used uninitialized [-Werror=uninitialized] 412 | struct dimm_data dimm_info[IE31200_CHANNELS][IE31200_DIMMS_PER_CHANNEL]; | ^~~~~~~~~ drivers/edac/ie31200_edac.c:412:26: note: 'dimm_info' declared here 412 | struct dimm_data dimm_info[IE31200_CHANNELS][IE31200_DIMMS_PER_CHANNEL]; | ^~~~~~~~~ I don't see any way the unintialized access could really happen here, but I can see why the compiler gets confused by the two loops. Instead, rework the two nested loops to only read the addr_decode registers and then keep only one instance of the dimm info structure. [Tony: Qiuxu pointed out that the "populate DIMM info" comment was left behind in the refactor and suggested moving it. I deleted the comment as unnecessry in front os a call to populate_dimm_info(). That seems pretty self-describing.] Signed-off-by: Arnd Bergmann Acked-by: Jason Baron Signed-off-by: Tony Luck Link: https://lore.kernel.org/all/20250122065031.1321015-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 4593aaf48fc16c7a06d05dd2db4b35d0deec718d Author: Chris Morgan Date: Tue Feb 4 09:58:33 2025 -0600 power: supply: axp20x_battery: Update temp sensor for AXP717 from device tree [ Upstream commit bbcfe510ecd47f2db4c8653c7dfa9dc7a55b1583 ] Allow a boolean property of "x-powers,no-thermistor" to specify devices where the ts pin is not connected to anything. This works around an issue found with some devices where the efuse is not programmed correctly from the factory or when the register gets set erroneously. Signed-off-by: Chris Morgan Tested-by: Philippe Simons Link: https://lore.kernel.org/r/20250204155835.161973-4-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6b1d3e9db82d01a88de1795b879df67c2116b4f4 Author: Peter Seiderer Date: Wed Feb 19 09:45:27 2025 +0100 net: pktgen: fix access outside of user given buffer in pktgen_thread_write() [ Upstream commit 425e64440ad0a2f03bdaf04be0ae53dededbaa77 ] Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer). Signed-off-by: Peter Seiderer Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250219084527.20488-8-ps.report@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d37783f25a3c8aa32d7fb2d61941dbbcd1ddb62b Author: Kuan-Chung Chen Date: Mon Feb 17 14:12:35 2025 +0800 wifi: rtw89: 8922a: fix incorrect STA-ID in EHT MU PPDU [ Upstream commit bdce0574243b43b3bb2064f609c0c326df44c4c6 ] EHT MU PPDU contains user field of EHT-SIG field with STA-ID that must match AID subfield in the Associate Response. Add a necessary setting to prevent these from being inconsistent. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250217061235.32031-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 7dafba4e854cd489790213a1af04986342b09c18 Author: Ping-Ke Shih Date: Mon Feb 17 14:43:04 2025 +0800 wifi: rtw89: fw: add blacklist to avoid obsolete secure firmware [ Upstream commit f11d042b3a2e92ab1aa10e0da8e290bcdcf31d39 ] To ensure secure chip only runs expected secure firmware, stop using obsolete firmware in blacklist which weakness or flaw was found. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250217064308.43559-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 6ffcf25e6322630cc495fb3cde7f0e9ca56afc72 Author: Ping-Ke Shih Date: Mon Feb 17 14:43:05 2025 +0800 wifi: rtw89: fw: get sb_sel_ver via get_unaligned_le32() [ Upstream commit 2f9da853f4d848d23bade4c22931ea0f5a011674 ] The sb_sel_ver is selection version for secure boot recorded in firmware binary data, and its size is 4 and offset is 58 (not natural alignment). Use get_unaligned_le32() to get this value safely. Find this by reviewing. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250217064308.43559-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit 1cbef396c5f3bf89f4787c975d85533f373bb9ad Author: Ping-Ke Shih Date: Mon Feb 17 14:43:06 2025 +0800 wifi: rtw89: fw: propagate error code from rtw89_h2c_tx() [ Upstream commit 56e1acaa0f80620b8e2c3410db35b4b975782b0a ] The error code should be propagated to callers during downloading firmware header and body. Remove unnecessary assignment of -1. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250217064308.43559-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit a4523765fa3a9f58012904c0329a8bb93ba20b0e Author: Bitterblue Smith Date: Tue Feb 18 01:29:52 2025 +0200 wifi: rtw88: Fix rtw_desc_to_mcsrate() to handle MCS16-31 [ Upstream commit 86d04f8f991a0509e318fe886d5a1cf795736c7d ] This function translates the rate number reported by the hardware into something mac80211 can understand. It was ignoring the 3SS and 4SS HT rates. Translate them too. Also set *nss to 0 for the HT rates, just to make sure it's initialised. Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/d0a5a86b-4869-47f6-a5a7-01c0f987cc7f@gmail.com Signed-off-by: Sasha Levin commit adcc65afaa97921d430a662229ae8e573a4a8dec Author: Bitterblue Smith Date: Tue Feb 18 01:30:22 2025 +0200 wifi: rtw88: Fix rtw_init_ht_cap() for RTL8814AU [ Upstream commit c7eea1ba05ca5b0dbf77a27cf2e1e6e2fb3c0043 ] Set the RX mask and the highest RX rate according to the number of spatial streams the chip can receive. For RTL8814AU that is 3. Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/4e786f50-ed1c-4387-8b28-e6ff00e35e81@gmail.com Signed-off-by: Sasha Levin commit 9a3f80a727aac5e6c446d1386ad0c007734bf5cc Author: Bitterblue Smith Date: Tue Feb 18 01:30:48 2025 +0200 wifi: rtw88: Fix rtw_init_vht_cap() for RTL8814AU [ Upstream commit 6be7544d19fcfcb729495e793bc6181f85bb8949 ] Set the MCS maps and the highest rates according to the number of spatial streams the chip has. For RTL8814AU that is 3. Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/e86aa009-b5bf-4b3a-8112-ea5e3cd49465@gmail.com Signed-off-by: Sasha Levin commit 1653c72dabfd68b68e4aa94d10075a8f16ca3ac2 Author: Shivasharan S Date: Wed Feb 12 17:26:55 2025 -0800 scsi: mpt3sas: Send a diag reset if target reset fails [ Upstream commit 5612d6d51ed2634a033c95de2edec7449409cbb9 ] When an IOCTL times out and driver issues a target reset, if firmware fails the task management elevate the recovery by issuing a diag reset to controller. Signed-off-by: Shivasharan S Link: https://lore.kernel.org/r/1739410016-27503-5-git-send-email-shivasharan.srikanteshwara@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b5038d313a3b7fcf56b2e9853a7cf663dc83c47f Author: Mrinmay Sarkar Date: Thu Dec 5 12:24:20 2024 +0530 PCI: epf-mhi: Update device ID for SA8775P [ Upstream commit 4f13dd9e2b1d2b317bb36704f8a7bd1d3017f7a2 ] Update device ID for the Qcom SA8775P SoC. Signed-off-by: Mrinmay Sarkar Link: https://lore.kernel.org/r/20241205065422.2515086-3-quic_msarkar@quicinc.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 0b21e99cf638bc06f199204d2211034661f650b4 Author: Paul Burton Date: Wed Jan 29 13:32:47 2025 +0100 clocksource: mips-gic-timer: Enable counter when CPUs start [ Upstream commit 3128b0a2e0cf6e07aa78e5f8cf7dd9cd59dc8174 ] In multi-cluster MIPS I6500 systems there is a GIC in each cluster, each with its own counter. When a cluster powers up the counter will be stopped, with the COUNTSTOP bit set in the GIC_CONFIG register. In single cluster systems, it has been fine to clear COUNTSTOP once in gic_clocksource_of_init() to start the counter. In multi-cluster systems, this will only have started the counter in the boot cluster, and any CPUs in other clusters will find their counter stopped which will break the GIC clock_event_device. Resolve this by having CPUs clear the COUNTSTOP bit when they come online, using the existing gic_starting_cpu() CPU hotplug callback. This will allow CPUs in secondary clusters to ensure that the cluster's GIC counter is running as expected. Signed-off-by: Paul Burton Signed-off-by: Chao-ying Fu Signed-off-by: Dragan Mladjenovic Signed-off-by: Aleksandar Rikalo Reviewed-by: Philippe Mathieu-Daudé Tested-by: Serge Semin Tested-by: Gregory CLEMENT Acked-by: Daniel Lezcano Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1a3529f36f26ef8ecb9c1f4fef49c2af3986da6d Author: Paul Burton Date: Wed Jan 29 13:32:48 2025 +0100 MIPS: pm-cps: Use per-CPU variables as per-CPU, not per-core [ Upstream commit 00a134fc2bb4a5f8fada58cf7ff4259149691d64 ] The pm-cps code has up until now used per-CPU variables indexed by core, rather than CPU number, in order to share data amongst sibling CPUs (ie. VPs/threads in a core). This works fine for single cluster systems, but with multi-cluster systems a core number is no longer unique in the system, leading to sharing between CPUs that are not actually siblings. Avoid this issue by using per-CPU variables as they are more generally used - ie. access them using CPU numbers rather than core numbers. Sharing between siblings is then accomplished by: - Assigning the same pointer to entries for each sibling CPU for the nc_asm_enter & ready_count variables, which allow this by virtue of being per-CPU pointers. - Indexing by the first CPU set in a CPUs cpu_sibling_map in the case of pm_barrier, for which we can't use the previous approach because the per-CPU variable is not a pointer. Signed-off-by: Paul Burton Signed-off-by: Dragan Mladjenovic Signed-off-by: Aleksandar Rikalo Tested-by: Serge Semin Tested-by: Gregory CLEMENT Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 53f42776e435f63e5f8e61955e4c205dbfeaf524 Author: Jason Gunthorpe Date: Wed Feb 19 17:31:36 2025 -0800 genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie [ Upstream commit 1f7df3a691740a7736bbc99dc4ed536120eb4746 ] The IOMMU translation for MSI message addresses has been a 2-step process, separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached. Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up. However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()). This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs. Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor. The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex. Link: https://patch.msgid.link/r/a4f2cd76b9dc1833ee6c1cf325cba57def22231c.1740014950.git.nicolinc@nvidia.com Signed-off-by: Nicolin Chen Reviewed-by: Thomas Gleixner Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5111c2e0cf2b650ebf69003e3a75aa055eb9a3b0 Author: Uros Bizjak Date: Fri Feb 14 16:07:46 2025 +0100 x86/locking: Use ALT_OUTPUT_SP() for percpu_{,try_}cmpxchg{64,128}_op() [ Upstream commit 4087e16b033140cf2ce509ec23503bddec818a16 ] percpu_{,try_}cmpxchg{64,128}() macros use CALL instruction inside asm statement in one of their alternatives. Use ALT_OUTPUT_SP() macro to add required dependence on %esp register. ALT_OUTPUT_SP() implements the above dependence by adding ASM_CALL_CONSTRAINT to its arguments. This constraint should be used for any inline asm which has a CALL instruction, otherwise the compiler may schedule the asm before the frame pointer gets set up by the containing function, causing objtool to print a "call without frame pointer save/setup" warning. Signed-off-by: Uros Bizjak Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250214150929.5780-1-ubizjak@gmail.com Signed-off-by: Sasha Levin commit 95b8f2b7d9312054209bfd80460a1c6adae1ac29 Author: Christian König Date: Wed Jan 29 16:28:49 2025 +0100 drm/amdgpu: remove all KFD fences from the BO on release [ Upstream commit cb0de06d1b0afb2d0c600ad748069f5ce27730ec ] Remove all KFD BOs from the private dma_resv object. This prevents the KFD from being evict unecessarily when an exported BO is released. Signed-off-by: Christian König Signed-off-by: James Zhu Reviewed-by: Felix Kuehling Reviewed-and-tested-by: James Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit af706d0e279fcc8e181ebe539a26e3a203c469a3 Author: Bibo Mao Date: Tue Jun 9 10:54:35 2020 +0800 MIPS: Use arch specific syscall name match function [ Upstream commit 756276ce78d5624dc814f9d99f7d16c8fd51076e ] On MIPS system, most of the syscall function name begin with prefix sys_. Some syscalls are special such as clone/fork, function name of these begin with __sys_. Since scratch registers need be saved in stack when these system calls happens. With ftrace system call method, system call functions are declared with SYSCALL_DEFINEx, metadata of the system call symbol name begins with sys_. Here mips specific function arch_syscall_match_sym_name is used to compare function name between sys_call_table[] and metadata of syscall symbol. Signed-off-by: Bibo Mao Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 9058b48578aea5c59189ccb72abbd0bc9fa43a45 Author: Umesh Nerlige Ramappa Date: Tue Feb 11 17:02:55 2025 -0800 drm/xe/oa: Ensure that polled read returns latest data [ Upstream commit 98c9d27ab30aa9c6451d3a34e6e297171f273e51 ] In polled mode, user calls poll() for read data to be available before performing a read(). In the duration between these 2 calls, there may be new data available in the OA buffer. To ensure user reads all available data, check for latest data in the OA buffer in polled read. Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Ashutosh Dixit Link: https://patchwork.freedesktop.org/patch/msgid/20250212010255.1423343-1-umesh.nerlige.ramappa@intel.com Signed-off-by: Sasha Levin commit 4d9fa2ebc01c492bf478bbdbfc5c9ebd4b27aeb4 Author: Xiao Liang Date: Wed Feb 19 20:50:33 2025 +0800 net: ipv6: Init tunnel link-netns before registering dev [ Upstream commit db014522f35606031d8ac58b4aed6b1ed84f03d1 ] Currently some IPv6 tunnel drivers set tnl->net to dev_net(dev) in ndo_init(), which is called in register_netdevice(). However, it lacks the context of link-netns when we enable cross-net tunnels at device registration time. Let's move the init of tunnel link-netns before register_netdevice(). ip6_gre has already initialized netns, so just remove the redundant assignment. Signed-off-by: Xiao Liang Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250219125039.18024-8-shaw.leon@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 897c98fb328011461cc63ea1533688bdac035ad8 Author: Herbert Xu Date: Sat Feb 15 08:57:51 2025 +0800 crypto: skcipher - Zap type in crypto_alloc_sync_skcipher [ Upstream commit ee509efc74ddbc59bb5d6fd6e050f9ef25f74bff ] The type needs to be zeroed as otherwise the user could use it to allocate an asynchronous sync skcipher. Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9f27b38771b05067f5fadf4628296efb768e50d4 Author: Herbert Xu Date: Sun Feb 16 11:07:24 2025 +0800 crypto: ahash - Set default reqsize from ahash_alg [ Upstream commit 9e01aaa1033d6e40f8d7cf4f20931a61ce9e3f04 ] Add a reqsize field to struct ahash_alg and use it to set the default reqsize so that algorithms with a static reqsize are not forced to create an init_tfm function. Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 562e512f6bf999c9966baf64b4d9fded8071919e Author: Balbir Singh Date: Fri Feb 7 10:42:34 2025 +1100 x86/kaslr: Reduce KASLR entropy on most x86 systems [ Upstream commit 7ffb791423c7c518269a9aad35039ef824a40adb ] When CONFIG_PCI_P2PDMA=y (which is basically enabled on all large x86 distros), it maps the PFN's via a ZONE_DEVICE mapping using devm_memremap_pages(). The mapped virtual address range corresponds to the pci_resource_start() of the BAR address and size corresponding to the BAR length. When KASLR is enabled, the direct map range of the kernel is reduced to the size of physical memory plus additional padding. If the BAR address is beyond this limit, PCI peer to peer DMA mappings fail. Fix this by not shrinking the size of the direct map when CONFIG_PCI_P2PDMA=y. This reduces the total available entropy, but it's better than the current work around of having to disable KASLR completely. [ mingo: Clarified the changelog to point out the broad impact ... ] Signed-off-by: Balbir Singh Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Acked-by: Bjorn Helgaas # drivers/pci/Kconfig Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Andy Lutomirski Link: https://lore.kernel.org/lkml/20250206023201.1481957-1-balbirs@nvidia.com/ Link: https://lore.kernel.org/r/20250206234234.1912585-1-balbirs@nvidia.com -- arch/x86/mm/kaslr.c | 10 ++++++++-- drivers/pci/Kconfig | 6 ++++++ 2 files changed, 14 insertions(+), 2 deletions(-) Signed-off-by: Sasha Levin commit 0bdaab17a2a177bbb8dfa96cf1413d183e8b6ea6 Author: Patrisious Haddad Date: Wed Feb 19 10:58:08 2025 +0200 net/mlx5: Change POOL_NEXT_SIZE define value and make it global [ Upstream commit 80df31f384b4146a62a01b3d4beb376cc7b9a89e ] Change POOL_NEXT_SIZE define value from 0 to BIT(30), since this define is used to request the available maximum sized flow table, and zero doesn't make sense for it, whereas some places in the driver use zero explicitly expecting the smallest table size possible but instead due to this define they end up allocating the biggest table size unawarely. In addition move the definition to "include/linux/mlx5/fs.h" to expose the define to IB driver as well, while appropriately renaming it. Signed-off-by: Patrisious Haddad Reviewed-by: Maor Gottlieb Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20250219085808.349923-3-tariqt@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d2d76fc02543a94fc126d8c8e490aa2f9a7ce5fb Author: Kai Mäkisara Date: Thu Feb 13 11:26:30 2025 +0200 scsi: scsi_debug: First fixes for tapes [ Upstream commit f69da85d5d5cc5b7dfb963a6c6c1ac0dd9002341 ] Patch includes the following: - Enable MODE SENSE/SELECT without actual page (to read/write only the Block Descriptor) - Store the density code and block size in the Block Descriptor (only short version for tapes) - Fix REWIND not to use the wrong page filling function Signed-off-by: Kai Mäkisara Link: https://lore.kernel.org/r/20250213092636.2510-2-Kai.Makisara@kolumbus.fi Reviewed-by: John Meneghini Tested-by: John Meneghini Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b55a97d1bd4083729a60d19beffe85d4c96680de Author: Jinliang Zheng Date: Thu Feb 20 19:20:14 2025 +0800 dm: fix unconditional IO throttle caused by REQ_PREFLUSH [ Upstream commit 88f7f56d16f568f19e1a695af34a7f4a6ce537a6 ] When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait(). Signed-off-by: Jinliang Zheng Reviewed-by: Tianxiang Peng Reviewed-by: Hao Peng Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 2c600cbe33f2072b218037895b58753cc49e5e97 Author: Nandakumar Edamana Date: Sat Feb 22 02:31:11 2025 +0530 libbpf: Fix out-of-bound read [ Upstream commit 236d3910117e9f97ebf75e511d8bcc950f1a4e5f ] In `set_kcfg_value_str`, an untrusted string is accessed with the assumption that it will be at least two characters long due to the presence of checks for opening and closing quotes. But the check for the closing quote (value[len - 1] != '"') misses the fact that it could be checking the opening quote itself in case of an invalid input that consists of just the opening quote. This commit adds an explicit check to make sure the string is at least two characters long. Signed-off-by: Nandakumar Edamana Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250221210110.3182084-1-nandakumar@nandakumar.co.in Signed-off-by: Sasha Levin commit 20a53c3689a20a5e34b88fc7705b7f0bf883eb1c Author: Christoph Hellwig Date: Fri Jan 31 13:00:40 2025 +0100 loop: check in LO_FLAGS_DIRECT_IO in loop_default_blocksize [ Upstream commit f6f9e32fe1e454ae8ac0190b2c2bd6074914beec ] We can't go below the minimum direct I/O size no matter if direct I/O is enabled by passing in an O_DIRECT file descriptor or due to the explicit flag. Now that LO_FLAGS_DIRECT_IO is set earlier after assigning a backing file, loop_default_blocksize can check it instead of the O_DIRECT flag to handle both conditions. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20250131120120.1315125-4-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5b62f941eae80688aecbbbaed44b51cbb0fe1fa7 Author: Ranjan Kumar Date: Thu Feb 20 19:55:26 2025 +0530 scsi: mpi3mr: Update timestamp only for supervisor IOCs [ Upstream commit 83a9d30d29f275571f6e8f879f04b2379be7eb6c ] The driver issues the time stamp update command periodically. Even if the command fails with supervisor only IOC Status. Instead check the Non-Supervisor capability bit reported by IOC as part of IOC Facts. Co-developed-by: Sumit Saxena Signed-off-by: Sumit Saxena Signed-off-by: Ranjan Kumar Link: https://lore.kernel.org/r/20250220142528.20837-3-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a68686c08b70bdad0b1a406bcfe7e07f3bdc5da2 Author: Jianbo Liu Date: Thu Feb 20 23:39:53 2025 +0200 net/mlx5e: Add correct match to check IPSec syndromes for switchdev mode [ Upstream commit 85e4a808af2545fefaf18c8fe50071b06fcbdabc ] In commit dddb49b63d86 ("net/mlx5e: Add IPsec and ASO syndromes check in HW"), IPSec and ASO syndromes checks after decryption for the specified ASO object were added. But they are correct only for eswith in legacy mode. For switchdev mode, metadata register c1 is used to save the mapped id (not ASO object id). So, need to change the match accordingly for the check rules in status table. Signed-off-by: Jianbo Liu Reviewed-by: Leon Romanovsky Reviewed-by: Patrisious Haddad Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20250220213959.504304-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c2aa6567a6a486a61325eb222afbebf28768989f Author: Matthias Fend Date: Tue Jan 7 17:07:01 2025 +0100 media: tc358746: improve calculation of the D-PHY timing registers [ Upstream commit 78d7265e2e1ce349e7f3c6a085f2b66d7b73f4ca ] When calculating D-PHY registers, using data rates that are not multiples of 16 can lead to precision loss in division operations. This can result in register values that produce timing violations against the MIPI standard. An example: cfg->hs_clk_rate = 294MHz hf_clk = 18 If the desired value in cfg->init is 100us, which is the minimum allowed value, then the LINEINITCNT register is calculated as 1799. But since the actual clock is 18.375MHz instead of 18MHz, this setting results in a time that is shorter than 100us and thus violates the standard. The correct value for LINEINITCNT would be 1837. Improve the precision of calculations by using Hz instead of MHz as unit. Signed-off-by: Matthias Fend Reviewed-by: Marco Felsch Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit bb8fb041cba26793200d006231fab765ee63ed64 Author: Niklas Söderlund Date: Sat Feb 22 00:09:07 2025 +0100 media: adv7180: Disable test-pattern control on adv7180 [ Upstream commit a980bc5f56b0292336e408f657f79e574e8067c0 ] The register that enables selecting a test-pattern to be outputted in free-run mode (FREE_RUN_PAT_SEL[2:0]) is only available on adv7280 based devices, not the adv7180 based ones. Add a flag to mark devices that are capable of generating test-patterns, and those that are not. And only register the control on supported devices. Signed-off-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 083383aba01f278080938e3b71dbfa7256648ca4 Author: Rafael J. Wysocki Date: Thu Feb 6 15:29:05 2025 +0100 cpuidle: menu: Avoid discarding useful information [ Upstream commit 85975daeaa4d6ec560bfcd354fc9c08ad7f38888 ] When giving up on making a high-confidence prediction, get_typical_interval() always returns UINT_MAX which means that the next idle interval prediction will be based entirely on the time till the next timer. However, the information represented by the most recent intervals may not be completely useless in those cases. Namely, the largest recent idle interval is an upper bound on the recently observed idle duration, so it is reasonable to assume that the next idle duration is unlikely to exceed it. Moreover, this is still true after eliminating the suspected outliers if the sample set still under consideration is at least as large as 50% of the maximum sample set size. Accordingly, make get_typical_interval() return the current maximum recent interval value in that case instead of UINT_MAX. Signed-off-by: Rafael J. Wysocki Reported-by: Artem Bityutskiy Tested-by: Artem Bityutskiy Reviewed-by: Christian Loehle Tested-by: Christian Loehle Tested-by: Aboorva Devarajan Link: https://patch.msgid.link/7770672.EvYhyI6sBW@rjwysocki.net Signed-off-by: Sasha Levin commit 0d508cefcd24a3ac1b934313d647ebd68bf9b946 Author: Konstantin Shkolnyy Date: Tue Feb 4 11:31:27 2025 -0600 vdpa/mlx5: Fix mlx5_vdpa_get_config() endianness on big-endian machines [ Upstream commit 439252e167ac45a5d46f573aac1da7d8f3e051ad ] mlx5_vdpa_dev_add() doesn’t initialize mvdev->actual_features. It’s initialized later by mlx5_vdpa_set_driver_features(). However, mlx5_vdpa_get_config() depends on the VIRTIO_F_VERSION_1 flag in actual_features, to return data with correct endianness. When it’s called before mlx5_vdpa_set_driver_features(), the data are incorrectly returned as big-endian on big-endian machines, while QEMU then interprets them as little-endian. The fix is to initialize this VIRTIO_F_VERSION_1 as early as possible, especially considering that mlx5_vdpa_dev_add() insists on this flag to always be set anyway. Signed-off-by: Konstantin Shkolnyy Message-Id: <20250204173127.166673-1-kshk@linux.ibm.com> Signed-off-by: Michael S. Tsirkin Reviewed-by: Dragos Tatulea Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 6398dd09d50b432e4d01fa8cfa8c3ae854fdf0f9 Author: Mike Christie Date: Tue Dec 3 13:15:11 2024 -0600 vhost-scsi: Return queue full for page alloc failures during copy [ Upstream commit 891b99eab0f89dbe08d216f4ab71acbeaf7a3102 ] This has us return queue full if we can't allocate a page during the copy operation so the initiator can retry. Signed-off-by: Mike Christie Message-Id: <20241203191705.19431-5-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Acked-by: Stefan Hajnoczi Signed-off-by: Sasha Levin commit 7eb29d704d2760454d39c2a6c63460d7ff79892d Author: Waiman Long Date: Thu Feb 6 14:18:44 2025 -0500 x86/nmi: Add an emergency handler in nmi_desc & use it in nmi_shootdown_cpus() [ Upstream commit fe37c699ae3eed6e02ee55fbf5cb9ceb7fcfd76c ] Depending on the type of panics, it was found that the __register_nmi_handler() function can be called in NMI context from nmi_shootdown_cpus() leading to a lockdep splat: WARNING: inconsistent lock state inconsistent {INITIAL USE} -> {IN-NMI} usage. lock(&nmi_desc[0].lock); lock(&nmi_desc[0].lock); Call Trace: _raw_spin_lock_irqsave __register_nmi_handler nmi_shootdown_cpus kdump_nmi_shootdown_cpus native_machine_crash_shutdown __crash_kexec In this particular case, the following panic message was printed before: Kernel panic - not syncing: Fatal hardware error! This message seemed to be given out from __ghes_panic() running in NMI context. The __register_nmi_handler() function which takes the nmi_desc lock with irq disabled shouldn't be called from NMI context as this can lead to deadlock. The nmi_shootdown_cpus() function can only be invoked once. After the first invocation, all other CPUs should be stuck in the newly added crash_nmi_callback() and cannot respond to a second NMI. Fix it by adding a new emergency NMI handler to the nmi_desc structure and provide a new set_emergency_nmi_handler() helper to set crash_nmi_callback() in any context. The new emergency handler will preempt other handlers in the linked list. That will eliminate the need to take any lock and serve the panic in NMI use case. Signed-off-by: Waiman Long Signed-off-by: Ingo Molnar Acked-by: Rik van Riel Cc: Thomas Gleixner Link: https://lore.kernel.org/r/20250206191844.131700-1-longman@redhat.com Signed-off-by: Sasha Levin commit 7bbfaa24c02f46ad06ac44cc7f4d3b194ce9a2fb Author: Nícolas F. R. A. Prado Date: Tue Feb 25 11:33:48 2025 -0300 ASoC: mediatek: mt8188: Add reference for dmic clocks [ Upstream commit bf1800073f4d55f08191b034c86b95881e99b6fd ] Add the names for the dmic clocks, aud_afe_dmic* and aud_dmic_hires*, so they can be acquired and enabled by the platform driver. Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20250225-genio700-dmic-v2-2-3076f5b50ef7@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4a21b57d83c553bd96577be4b9fb5eeaf1f3ec5c Author: Nícolas F. R. A. Prado Date: Tue Feb 25 11:33:49 2025 -0300 ASoC: mediatek: mt8188: Treat DMIC_GAINx_CUR as non-volatile [ Upstream commit 7d87bde21c73731ddaf15e572020f80999c38ee3 ] The DMIC_GAINx_CUR registers contain the current (as in present) gain of each DMIC. During capture, this gain will ramp up until a target value is reached, and therefore the register is volatile since it is updated automatically by hardware. However, after capture the register's value returns to the value that was written to it. So reading these registers returns the current gain, and writing configures the initial gain for every capture. >From an audio configuration perspective, reading the instantaneous gain is not really useful. Instead, reading back the initial gain that was configured is the desired behavior. For that reason, consider the DMIC_GAINx_CUR registers as non-volatile, so the regmap's cache can be used to retrieve the values, rather than requiring pm runtime resuming the device. Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20250225-genio700-dmic-v2-3-3076f5b50ef7@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6e5935b755b4a81ccebde4eed0ebd37f5875ddb3 Author: Assadian, Navid Date: Thu Dec 19 17:19:09 2024 -0500 drm/amd/display: Fix mismatch type comparison [ Upstream commit 26873260d394b1e33cdd720154aedf0af95327f9 ] The mismatch type comparison/assignment may cause data loss. Since the values are always non-negative, it is safe to use unsigned variables to resolve the mismatch. Signed-off-by: Navid Assadian Reviewed-by: Joshua Aberback Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 990e4fb37bcd49161bbc5331a24b73616aefafbf Author: Charlene Liu Date: Thu Feb 13 12:37:10 2025 -0500 drm/amd/display: fix dcn4x init failed [ Upstream commit 23ef388a84c72b0614a6c10f866ffeac7e807719 ] [why] failed due to cmdtable not created. switch atombios cmdtable as default. Reviewed-by: Alvin Lee Signed-off-by: Charlene Liu Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 54dd746ed8a30175444076c9b4fdd15cf86e0842 Author: Yihan Zhu Date: Wed Feb 12 15:17:56 2025 -0500 drm/amd/display: handle max_downscale_src_width fail check [ Upstream commit 02a940da2ccc0cc0299811379580852b405a0ea2 ] [WHY] If max_downscale_src_width check fails, we exit early from TAP calculation and left a NULL value to the scaling data structure to cause the zero divide in the DML validation. [HOW] Call set default TAP calculation before early exit in get_optimal_number_of_taps due to max downscale limit exceed. Reviewed-by: Samson Tam Signed-off-by: Yihan Zhu Signed-off-by: Zaeem Mohamed Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5cab1de0cea2840a8a7d061ae13413fb77ff96c0 Author: Nir Lichtman Date: Fri Jan 10 12:05:00 2025 +0000 x86/build: Fix broken copy command in genimage.sh when making isoimage [ Upstream commit e451630226bd09dc730eedb4e32cab1cc7155ae8 ] Problem: Currently when running the "make isoimage" command there is an error related to wrong parameters passed to the cp command: "cp: missing destination file operand after 'arch/x86/boot/isoimage/'" This is caused because FDINITRDS is an empty array. Solution: Check if FDINITRDS is empty before executing the "cp" command, similar to how it is done in the case of hdimage. Signed-off-by: Nir Lichtman Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Ard Biesheuvel Cc: Masahiro Yamada Cc: Michal Marek Link: https://lore.kernel.org/r/20250110120500.GA923218@lichtman.org Signed-off-by: Sasha Levin commit de48b82dcf583563227ea84606ffd1d4eab44404 Author: Hariprasad Kelam Date: Mon Feb 24 09:26:03 2025 +0530 Octeontx2-af: RPM: Register driver with PCI subsys IDs [ Upstream commit fc9167192f29485be5621e2e9c8208b717b65753 ] Although the PCI device ID and Vendor ID for the RPM (MAC) block have remained the same across Octeon CN10K and the next-generation CN20K silicon, Hardware architecture has changed (NIX mapped RPMs and RFOE Mapped RPMs). Add PCI Subsystem IDs to the device table to ensure that this driver can be probed from NIX mapped RPM devices only. Signed-off-by: Hariprasad Kelam Link: https://patch.msgid.link/20250224035603.1220913-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 673dde8d3c3ec97d10312caced2143194873de6f Author: Amery Hung Date: Tue Feb 25 15:35:44 2025 -0800 bpf: Search and add kfuncs in struct_ops prologue and epilogue [ Upstream commit d519594ee2445d7cd1ad51f4db4cee58f8213400 ] Currently, add_kfunc_call() is only invoked once before the main verification loop. Therefore, the verifier could not find the bpf_kfunc_btf_tab of a new kfunc call which is not seen in user defined struct_ops operators but introduced in gen_prologue or gen_epilogue during do_misc_fixup(). Fix this by searching kfuncs in the patching instruction buffer and add them to prog->aux->kfunc_tab. Signed-off-by: Amery Hung Acked-by: Eduard Zingerman Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/r/20250225233545.285481-1-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 06100e642f4b83ec758744e5f992d7a2039ec98f Author: Andrew Davis Date: Thu Jan 23 12:17:26 2025 -0600 soc: ti: k3-socinfo: Do not use syscon helper to build regmap [ Upstream commit a5caf03188e44388e8c618dcbe5fffad1a249385 ] The syscon helper device_node_to_regmap() is used to fetch a regmap registered to a device node. It also currently creates this regmap if the node did not already have a regmap associated with it. This should only be used on "syscon" nodes. This driver is not such a device and instead uses device_node_to_regmap() on its own node as a hacky way to create a regmap for itself. This will not work going forward and so we should create our regmap the normal way by defining our regmap_config, fetching our memory resource, then using the normal regmap_init_mmio() function. Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20250123181726.597144-1-afd@ti.com Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 54ef1a89e287ee81382358889a1e8b9637879af4 Author: Ramasamy Kaliappan Date: Fri Feb 7 11:30:05 2025 +0530 wifi: ath12k: Improve BSS discovery with hidden SSID in 6 GHz band [ Upstream commit 27d38bdfd416f4db70e09c3bef3b030c86fd235a ] Currently, sometimes, the station is unable to identify the configured AP SSID in its scan results when the AP is not broadcasting its name publicly and has a hidden SSID. Currently, channel dwell time for an ath12k station is 30 ms. Sometimes, station can send broadcast probe request to AP close to the end of dwell time. In some of these cases, before AP sends a response to the received probe request, the dwell time on the station side would come to an end. So, the station will move to scan next channel and will not be able to acknowledge the unicast probe response. Resolve this issue by increasing station's channel dwell time to 70 ms, so that the it remains on the same channel for a longer period. This would increase the station's chance of receiving probe response from the AP. The station will then send a response acknowledgment back to the AP, thus leading to successful scan and BSS discovery. With an increased dwell time, scan would take longer than it takes now. But, this fix is an improvement for hidden SSID scan issue. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Ramasamy Kaliappan Signed-off-by: Roopni Devanathan Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250207060005.153835-1-quic_rdevanat@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e39fd41117bd94b2e992f857cd77cf07972566e6 Author: Hangbin Liu Date: Tue Feb 25 03:39:14 2025 +0000 bonding: report duplicate MAC address in all situations [ Upstream commit 28d68d396a1cd21591e8c6d74afbde33a7ea107e ] Normally, a bond uses the MAC address of the first added slave as the bond’s MAC address. And the bond will set active slave’s MAC address to bond’s address if fail_over_mac is set to none (0) or follow (2). When the first slave is removed, the bond will still use the removed slave’s MAC address, which can lead to a duplicate MAC address and potentially cause issues with the switch. To avoid confusion, let's warn the user in all situations, including when fail_over_mac is set to 2 or not in active-backup mode. Signed-off-by: Hangbin Liu Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250225033914.18617-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f872f7aaa4cac5f4c1dcae4a0489374735ff1048 Author: Arnd Bergmann Date: Tue Feb 25 17:33:33 2025 +0100 net: xgene-v2: remove incorrect ACPI_PTR annotation [ Upstream commit 01358e8fe922f716c05d7864ac2213b2440026e7 ] Building with W=1 shows a warning about xge_acpi_match being unused when CONFIG_ACPI is disabled: drivers/net/ethernet/apm/xgene-v2/main.c:723:36: error: unused variable 'xge_acpi_match' [-Werror,-Wunused-const-variable] Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20250225163341.4168238-2-arnd@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 459b3f7cf0dcfa7f4fa1b8ccab8a176e96ebcf48 Author: Eric Woudstra Date: Tue Feb 25 21:15:09 2025 +0100 net: ethernet: mtk_ppe_offload: Allow QinQ, double ETH_P_8021Q only [ Upstream commit 7fe0353606d77a32c4c7f2814833dd1c043ebdd2 ] mtk_foe_entry_set_vlan() in mtk_ppe.c already supports double vlan tagging, but mtk_flow_offload_replace() in mtk_ppe_offload.c only allows for 1 vlan tag, optionally in combination with pppoe and dsa tags. However, mtk_foe_entry_set_vlan() only allows for setting the vlan id. The protocol cannot be set, it is always ETH_P_8021Q, for inner and outer tag. This patch adds QinQ support to mtk_flow_offload_replace(), only in the case that both inner and outer tags are ETH_P_8021Q. Only PPPoE-in-Q (as before) and Q-in-Q are allowed. A combination of PPPoE and Q-in-Q is not allowed. Signed-off-by: Eric Woudstra Link: https://patch.msgid.link/20250225201509.20843-1-ericwouds@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 562b4f70bf88add47ef146e02bf972b9a8ab370d Author: Yuanjun Gong Date: Sun Feb 23 20:14:59 2025 +0800 leds: pwm-multicolor: Add check for fwnode_property_read_u32 [ Upstream commit 6d91124e7edc109f114b1afe6d00d85d0d0ac174 ] Add a check to the return value of fwnode_property_read_u32() in case it fails. Signed-off-by: Yuanjun Gong Link: https://lore.kernel.org/r/20250223121459.2889484-1-ruc_gongyuanjun@163.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b8fcb1cdbfc0c876a443d34ae3fe5154d6642715 Author: Daniel Gomez Date: Mon Feb 24 07:23:13 2025 +0100 drm/xe: xe_gen_wa_oob: replace program_invocation_short_name [ Upstream commit 89eb42b5539f6ae6a0cabcb39e5b6fcc83c106a1 ] program_invocation_short_name may not be available in other systems. Instead, replace it with the argv[0] to pass the executable name. Fixes build error when program_invocation_short_name is not available: drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of undeclared identifier 'program_invocation_short_name' 34 | program_invocation_short_name); | ^ 1 error generated. Suggested-by: Masahiro Yamada Signed-off-by: Daniel Gomez Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20250224-macos-build-support-xe-v3-1-d2c9ed3a27cc@samsung.com Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 0d8562e358176106d9a0a3c8932cf706119eccde Author: Philip Yang Date: Mon Feb 17 20:08:29 2025 -0500 drm/amdkfd: KFD release_work possible circular locking [ Upstream commit 1b9366c601039d60546794c63fbb83ce8e53b978 ] If waiting for gpu reset done in KFD release_work, thers is WARNING: possible circular locking dependency detected #2 kfd_create_process kfd_process_mutex flush kfd release work #1 kfd release work wait for amdgpu reset work #0 amdgpu_device_gpu_reset kgd2kfd_pre_reset kfd_process_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&p->release_work)); lock((wq_completion)kfd_process_wq); lock((work_completion)(&p->release_work)); lock((wq_completion)amdgpu-reset-dev); To fix this, KFD create process move flush release work outside kfd_process_mutex. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1dd943dfb56f86f65f624cad9fb1834a3cb717fe Author: Inochi Amaoto Date: Tue Feb 11 13:17:49 2025 +0800 pinctrl: sophgo: avoid to modify untouched bit when setting cv1800 pinconf [ Upstream commit ef1a5121ae3da02372fcb66d9632ed3d47ad5637 ] When setting pinconf configuration for cv1800 SoC, the driver just writes the value. It may zero some bits of the pinconf register and cause some unexpected error. Add a mask to avoid this. Signed-off-by: Inochi Amaoto Link: https://lore.kernel.org/20250211051801.470800-2-inochiama@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit baaf3084c2cb92933c7ec29d584bccd1e9183a2a Author: Kevin Krakauer Date: Wed Feb 26 11:27:23 2025 -0800 selftests/net: have `gro.sh -t` return a correct exit code [ Upstream commit 784e6abd99f24024a8998b5916795f0bec9d2fd9 ] Modify gro.sh to return a useful exit code when the -t flag is used. It formerly returned 0 no matter what. Tested: Ran `gro.sh -t large` and verified that test failures return 1. Signed-off-by: Kevin Krakauer Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250226192725.621969-2-krakauer@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11e721443c5647a2b1c005a598438890d8dcfd3b Author: Moshe Shemesh Date: Wed Feb 26 14:25:40 2025 +0200 net/mlx5: Avoid report two health errors on same syndrome [ Upstream commit b5d7b2f04ebcff740f44ef4d295b3401aeb029f4 ] In case health counter has not increased for few polling intervals, miss counter will reach max misses threshold and health report will be triggered for FW health reporter. In case syndrome found on same health poll another health report will be triggered. Avoid two health reports on same syndrome by marking this syndrome as already known. Signed-off-by: Moshe Shemesh Reviewed-by: Shahar Shitrit Signed-off-by: Tariq Toukan Reviewed-by: Kalesh AP Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f512005f497dab8fb62218a3256ce1547ad9d1a Author: Satyanarayana K V P Date: Mon Feb 24 15:58:06 2025 +0530 drm/xe/pf: Create a link between PF and VF devices [ Upstream commit 8c0aff7d92e2be25717669eb65a81a89740a24f2 ] When both PF and VF devices are enabled on the host, they resume simultaneously during system resume. However, the PF must finish provisioning the VF before any VFs can successfully resume. Establish a parent-child device link between the PF and VF devices to ensure the correct order of resumption. V4 -> V5: - Added missing break in the error condition. V3 -> V4: - Made xe_pci_pf_get_vf_dev() as a static function and updated input parameter types. - Updated xe_sriov_warn() to xe_sriov_abort() when VF device cannot be found. V2 -> V3: - Added function documentation for xe_pci_pf_get_vf_dev(). - Added assertion if not called from PF. V1 -> V2: - Added a helper function to get VF pci_dev. - Updated xe_sriov_notice() to xe_sriov_warn() if vf pci_dev is not found. Signed-off-by: Satyanarayana K V P Cc: Michał Wajdeczko Cc: Michał Winiarski Cc: Piotr Piórkowski Reviewed-by: Piotr Piorkowski Signed-off-by: Michal Wajdeczko Link: https://patchwork.freedesktop.org/patch/msgid/20250224102807.11065-2-satyanarayana.k.v.p@intel.com Signed-off-by: Sasha Levin commit df888ad55f8f8aaf22bbeafcee6bf7c27374bba3 Author: Satyanarayana K V P Date: Mon Feb 24 15:58:07 2025 +0530 drm/xe/vf: Retry sending MMIO request to GUC on timeout error [ Upstream commit ba757a65d2a28d46a8ccf50538f4f05036983f1b ] Add support to allow retrying the sending of MMIO requests from the VF to the GUC in the event of an error. During the suspend/resume process, VFs begin resuming only after the PF has resumed. Although the PF resumes, the GUC reset and provisioning occur later in a separate worker process. When there are a large number of VFs, some may attempt to resume before the PF has completed its provisioning. Therefore, if a MMIO request from a VF fails during this period, we will retry sending the request up to GUC_RESET_VF_STATE_RETRY_MAX times, which is set to a maximum of 10 attempts. Signed-off-by: Satyanarayana K V P Cc: Michał Wajdeczko Cc: Michał Winiarski Cc: Piotr Piórkowski Reviewed-by: Piotr Piorkowski Signed-off-by: Michal Wajdeczko Link: https://patchwork.freedesktop.org/patch/msgid/20250224102807.11065-3-satyanarayana.k.v.p@intel.com Signed-off-by: Sasha Levin commit 3a3efeef64364c2a028cf0d03d68c831813a97fd Author: Viresh Kumar Date: Fri Jan 17 15:35:52 2025 +0530 firmware: arm_ffa: Set dma_mask for ffa devices [ Upstream commit cc0aac7ca17e0ea3ca84b552fc79f3e86fd07f53 ] Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124 Signed-off-by: Viresh Kumar Message-Id: Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 12153e3948c596737853c3ec4ff7e4e3f4a9f9a6 Author: Stanimir Varbanov Date: Mon Feb 24 10:35:56 2025 +0200 PCI: brcmstb: Add a softdep to MIP MSI-X driver [ Upstream commit 2294059118c550464dd8906286324d90c33b152b ] Then the brcmstb PCIe driver and MIP MSI-X interrupt controller drivers are built as modules there could be a race in probing. To avoid this, add a softdep to MIP driver to guarantee that MIP driver will be load first. Signed-off-by: Stanimir Varbanov Reviewed-by: Florian Fainelli Tested-by: Ivan T. Ivanov Link: https://lore.kernel.org/r/20250224083559.47645-5-svarbanov@suse.de [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 3ffaa2e999380477774e76680ff4cef247451168 Author: Stanimir Varbanov Date: Mon Feb 24 10:35:58 2025 +0200 PCI: brcmstb: Expand inbound window size up to 64GB [ Upstream commit 25a98c727015638baffcfa236e3f37b70cedcf87 ] The BCM2712 memory map can support up to 64GB of system memory, thus expand the inbound window size in calculation helper function. The change is safe for the currently supported SoCs that have smaller inbound window sizes. Signed-off-by: Stanimir Varbanov Reviewed-by: Florian Fainelli Reviewed-by: Jim Quinlan Tested-by: Ivan T. Ivanov Link: https://lore.kernel.org/r/20250224083559.47645-7-svarbanov@suse.de [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 7add9c10ca284b9ff599fa6a1faae3c357425db7 Author: Vinith Kumar R Date: Fri Nov 22 23:04:32 2024 +0530 wifi: ath12k: Report proper tx completion status to mac80211 [ Upstream commit d2d9c9b8de725e1006d3aa3d18678a732f5d3584 ] Currently Tx completion for few exception packets are received from firmware and the tx status updated to mac80211. The tx status values of HAL_WBM_REL_HTT_TX_COMP_STATUS_DROP and HAL_WBM_REL_HTT_TX_COMP_STATUS_TTL are considered as tx failure and reported as tx failure to mac80211. But these failure status is due to internal firmware tx drop and these packets were not tried to transmit in the air. In case of mesh this invalid tx status report might trigger mpath broken issue due to increase in mpath fail average. So do not report these tx status as tx failure instead free the skb by calling ieee80211_free_txskb(), and that will be accounted as dropped frame. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Vinith Kumar R Signed-off-by: Tamizh Chelvam Raja Acked-by: Jeff Johnson Link: https://patch.msgid.link/20241122173432.2064858-1-quic_tamizhr@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1c2c538bbd60288f5de1a70de1789d8a00294336 Author: Hector Martin Date: Wed Feb 26 19:00:04 2025 +0000 soc: apple: rtkit: Implement OSLog buffers properly [ Upstream commit a06398687065e0c334dc5fc4d2778b5b87292e43 ] Apparently nobody can figure out where the old logic came from, but it seems like it has never been actually used on any supported firmware to this day. OSLog buffers were apparently never requested. But starting with 13.3, we actually need this implemented properly for MTP (and later AOP) to work, so let's actually do that. Signed-off-by: Hector Martin Reviewed-by: Alyssa Rosenzweig Link: https://lore.kernel.org/r/20250226-apple-soc-misc-v2-2-c3ec37f9021b@svenpeter.dev Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit 92c6687ba951f311dc36c0bb7c62dd9b5fb9e244 Author: Janne Grunau Date: Wed Feb 26 19:00:05 2025 +0000 soc: apple: rtkit: Use high prio work queue [ Upstream commit 22af2fac88fa5dbc310bfe7d0b66d4de3ac47305 ] rtkit messages as communication with the DCP firmware for framebuffer swaps or input events are time critical so use WQ_HIGHPRI to prevent user space CPU load to increase latency. With kwin_wayland 6's explicit sync mode user space load was able to delay the IOMFB rtkit communication enough to miss vsync for surface swaps. Minimal test scenario is constantly resizing a glxgears Xwayland window. Signed-off-by: Janne Grunau Reviewed-by: Alyssa Rosenzweig Link: https://lore.kernel.org/r/20250226-apple-soc-misc-v2-3-c3ec37f9021b@svenpeter.dev Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit e359d62886cb1d7224e331575d6ab07f97b7fb14 Author: Rob Herring (Arm) Date: Tue Feb 18 14:39:56 2025 -0600 perf: arm_pmuv3: Call kvm_vcpu_pmu_resync_el0() before enabling counters [ Upstream commit 04bd15c4cbc3f7bd2399d1baab958c5e738dbfc9 ] Counting events related to setup of the PMU is not desired, but kvm_vcpu_pmu_resync_el0() is called just after the PMU counters have been enabled. Move the call to before enabling the counters. Signed-off-by: Rob Herring (Arm) Reviewed-by: Anshuman Khandual Tested-by: James Clark Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-1-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b38fbf98645be29e53f02380fa679237f667fded Author: Kuhanh Murugasen Krishnan Date: Thu Feb 13 06:12:49 2025 +0800 fpga: altera-cvp: Increase credit timeout [ Upstream commit 0f05886a40fdc55016ba4d9ae0a9c41f8312f15b ] Increase the timeout for SDM (Secure device manager) data credits from 20ms to 40ms. Internal stress tests running at 500 loops failed with the current timeout of 20ms. At the start of a FPGA configuration, the CVP host driver reads the transmit credits from SDM. It then sends bitstream FPGA data to SDM based on the total credits. Each credit allows the CVP host driver to send 4kBytes of data. There are situations whereby, the SDM did not respond in time during testing. Signed-off-by: Ang Tien Sung Signed-off-by: Kuhanh Murugasen Krishnan Acked-by: Xu Yilun Link: https://lore.kernel.org/r/20250212221249.2715929-1-tien.sung.ang@intel.com Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 7857d8977e9864fef9a61d98b3814dd71c64443f Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:47:58 2025 +0100 drm/mediatek: mtk_dpi: Add checks for reg_h_fre_con existence [ Upstream commit 8c9da7cd0bbcc90ab444454fecf535320456a312 ] In preparation for adding support for newer DPI instances which do support direct-pin but do not have any H_FRE_CON register, like the one found in MT8195 and MT8188, add a branch to check if the reg_h_fre_con variable was declared in the mtk_dpi_conf structure for the probed SoC DPI version. As a note, this is useful specifically only for cases in which the support_direct_pin variable is true, so mt8195-dpintf is not affected by any issue. Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-6-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 89800836bf32f5b0c14734c64d804fe73e34744f Author: Li Bin Date: Thu Feb 27 08:51:56 2025 -0700 ARM: at91: pm: fix at91_suspend_finish for ZQ calibration [ Upstream commit bc4722c3598d0e2c2dbf9609a3d3198993093e2b ] For sama7g5 and sama7d65 backup mode, we encountered a "ZQ calibrate error" during recalibrating the impedance in BootStrap. We found that the impedance value saved in at91_suspend_finish() before the DDR entered self-refresh mode did not match the resistor values. The ZDATA field in the DDR3PHY_ZQ0CR0 register uses a modified gray code to select the different impedance setting. But these gray code are incorrect, a workaournd from design team fixed the bug in the calibration logic. The ZDATA contains four independent impedance elements, but the algorithm combined the four elements into one. The elements were fixed using properly shifted offsets. Signed-off-by: Li Bin [nicolas.ferre@microchip.com: fix indentation and combine 2 patches] Signed-off-by: Nicolas Ferre Tested-by: Ryan Wanner Tested-by: Durai Manickam KR Tested-by: Andrei Simion Signed-off-by: Ryan Wanner Link: https://lore.kernel.org/r/28b33f9bcd0ca60ceba032969fe054d38f2b9577.1740671156.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit cd62e9d42fe76265d545a0c340e1d7307ba45808 Author: Alexander Stein Date: Mon Feb 10 15:59:30 2025 +0100 hwmon: (gpio-fan) Add missing mutex locks [ Upstream commit 9fee7d19bab635f89223cc40dfd2c8797fdc4988 ] set_fan_speed() is expected to be called with fan_data->lock being locked. Add locking for proper synchronization. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250210145934.761280-3-alexander.stein@ew.tq-group.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit e7e30a4a37d1e5fd0bae01a51ef738c17606f9f8 Author: Breno Leitao Date: Thu Oct 31 04:06:17 2024 -0700 x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2 [ Upstream commit 98fdaeb296f51ef08e727a7cc72e5b5c864c4f4d ] Change the default value of spectre v2 in user mode to respect the CONFIG_MITIGATION_SPECTRE_V2 config option. Currently, user mode spectre v2 is set to auto (SPECTRE_V2_USER_CMD_AUTO) by default, even if CONFIG_MITIGATION_SPECTRE_V2 is disabled. Set the spectre_v2 value to auto (SPECTRE_V2_USER_CMD_AUTO) if the Spectre v2 config (CONFIG_MITIGATION_SPECTRE_V2) is enabled, otherwise set the value to none (SPECTRE_V2_USER_CMD_NONE). Important to say the command line argument "spectre_v2_user" overwrites the default value in both cases. When CONFIG_MITIGATION_SPECTRE_V2 is not set, users have the flexibility to opt-in for specific mitigations independently. In this scenario, setting spectre_v2= will not enable spectre_v2_user=, and command line options spectre_v2_user and spectre_v2 are independent when CONFIG_MITIGATION_SPECTRE_V2=n. Signed-off-by: Breno Leitao Signed-off-by: Ingo Molnar Reviewed-by: Pawan Gupta Acked-by: Josh Poimboeuf Cc: Peter Zijlstra Cc: David Kaplan Link: https://lore.kernel.org/r/20241031-x86_bugs_last_v2-v2-2-b7ff1dab840e@debian.org Signed-off-by: Sasha Levin commit 0d232fa3b07690035da54836346898eab441a4ad Author: Ahmad Fatoum Date: Tue Feb 18 19:26:46 2025 +0100 clk: imx8mp: inform CCF of maximum frequency of clocks [ Upstream commit 06a61b5cb6a8638fa8823cd09b17233b29696fa2 ] The IMX8MPCEC datasheet lists maximum frequencies allowed for different modules. Some of these limits are universal, but some depend on whether the SoC is operating in nominal or in overdrive mode. The imx8mp.dtsi currently assumes overdrive mode and configures some clocks in accordance with this. Boards wishing to make use of nominal mode will need to override some of the clock rates manually. As operating the clocks outside of their allowed range can lead to difficult to debug issues, it makes sense to register the maximum rates allowed in the driver, so the CCF can take them into account. Reviewed-by: Peng Fan Signed-off-by: Ahmad Fatoum Link: https://lore.kernel.org/r/20250218-imx8m-clk-v4-6-b7697dc2dcd0@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 2d6231d5ce9b66cdb52c4d1a95d92a0ad5505515 Author: Ricardo Ribalda Date: Mon Feb 3 11:55:40 2025 +0000 media: uvcvideo: Handle uvc menu translation inside uvc_get_le_value [ Upstream commit 9109a0b4cb10fd681e9c6e9a4497a6fec5b91c39 ] map->get() gets a value from an uvc_control in "UVC format" and converts it to a value that can be consumed by v4l2. Instead of using a special get function for V4L2_CTRL_TYPE_MENU, we were converting from uvc_get_le_value in two different places. Move the conversion to uvc_get_le_value(). Reviewed-by: Hans de Goede Tested-by: Yunke Cao Signed-off-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20250203-uvc-roi-v17-4-5900a9fed613@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b98aad5e5ebf91f644401833b4015790e8880720 Author: Ricardo Ribalda Date: Mon Feb 3 11:55:51 2025 +0000 media: uvcvideo: Add sanity check to uvc_ioctl_xu_ctrl_map [ Upstream commit 990262fdfce24d6055df9711424343d94d829e6a ] Do not process unknown data types. Tested-by: Yunke Cao Reviewed-by: Hans de Goede Signed-off-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20250203-uvc-roi-v17-15-5900a9fed613@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 82209faa87f4aa36140039600714379233af290f Author: Caleb Sander Mateos Date: Tue Feb 25 14:24:55 2025 -0700 ublk: complete command synchronously on error [ Upstream commit 603f9be21c1894e462416e3324962d6c9c2b95f8 ] In case of an error, ublk's ->uring_cmd() functions currently return -EIOCBQUEUED and immediately call io_uring_cmd_done(). -EIOCBQUEUED and io_uring_cmd_done() are intended for asynchronous completions. For synchronous completions, the ->uring_cmd() function can just return the negative return code directly. This skips io_uring_cmd_del_cancelable(), and deferring the completion to task work. So return the error code directly from __ublk_ch_uring_cmd() and ublk_ctrl_uring_cmd(). Update ublk_ch_uring_cmd_cb(), which currently ignores the return value from __ublk_ch_uring_cmd(), to call io_uring_cmd_done() for synchronous completions. Signed-off-by: Caleb Sander Mateos Reviewed-by: Ming Lei Reviewed-by: Keith Busch Link: https://lore.kernel.org/r/20250225212456.2902549-1-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 564f03a7970c2c3695677d2f4bd3f1b0f23be3c1 Author: Christoph Hellwig Date: Tue Feb 25 07:44:31 2025 -0800 block: mark bounce buffering as incompatible with integrity [ Upstream commit 5fd0268a8806d35dcaf89139bfcda92be51b2b2f ] None of the few drivers still using the legacy block layer bounce buffering support integrity metadata. Explicitly mark the features as incompatible and stop creating the slab and mempool for integrity buffers for the bounce bio_set. Signed-off-by: Christoph Hellwig Reviewed-by: Anuj Gupta Reviewed-by: Martin K. Petersen Reviewed-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20250225154449.422989-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f7226dedac039dfb436f3e8999aa493d216801dc Author: Andy Yan Date: Mon Mar 3 11:44:17 2025 +0800 drm/rockchip: vop2: Add uv swap for cluster window [ Upstream commit e7aae9f6d762139f8d2b86db03793ae0ab3dd802 ] The Cluster windows of upcoming VOP on rk3576 also support linear YUV support, we need to set uv swap bit for it. As the VOP2_WIN_UV_SWA register defined on rk3568/rk3588 is 0xffffffff, so this register will not be touched on these two platforms. Signed-off-by: Andy Yan Tested-by: Michael Riesch # on RK3568 Tested-by: Detlev Casanova Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-4-andyshrk@163.com Signed-off-by: Sasha Levin commit f33b310eac36a5dfc844bfc7d17f67440a32d170 Author: Kuniyuki Iwashima Date: Thu Feb 27 20:23:27 2025 -0800 ipv4: fib: Move fib_valid_key_len() to rtm_to_fib_config(). [ Upstream commit 254ba7e6032d3fc738050d500b0c1d8197af90ca ] fib_valid_key_len() is called in the beginning of fib_table_insert() or fib_table_delete() to check if the prefix length is valid. fib_table_insert() and fib_table_delete() are called from 3 paths - ip_rt_ioctl() - inet_rtm_newroute() / inet_rtm_delroute() - fib_magic() In the first ioctl() path, rtentry_to_fib_config() checks the prefix length with bad_mask(). Also, fib_magic() always passes the correct prefix: 32 or ifa->ifa_prefixlen, which is already validated. Let's move fib_valid_key_len() to the rtnetlink path, rtm_to_fib_config(). While at it, 2 direct returns in rtm_to_fib_config() are changed to goto to match other places in the same function Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250228042328.96624-12-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3de322a98b365a7398d245d3de06971b3df1617f Author: Nicolas Bouchinet Date: Mon Feb 24 10:58:19 2025 +0100 scsi: logging: Fix scsi_logging_level bounds [ Upstream commit 2cef5b4472c602e6c5a119aca869d9d4050586f3 ] Bound scsi_logging_level sysctl writings between SYSCTL_ZERO and SYSCTL_INT_MAX. The proc_handler has thus been updated to proc_dointvec_minmax. Signed-off-by: Nicolas Bouchinet Link: https://lore.kernel.org/r/20250224095826.16458-5-nicolas.bouchinet@clip-os.org Reviewed-by: Joel Granados Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 500d22dbd966214cad9cfaed1d6f9e73689609de Author: Maciej S. Szmigiero Date: Sun Feb 16 22:31:03 2025 +0100 ALSA: hda/realtek: Enable PC beep passthrough for HP EliteBook 855 G7 [ Upstream commit aa85822c611aef7cd4dc17d27121d43e21bb82f0 ] PC speaker works well on this platform in BIOS and in Linux until sound card drivers are loaded. Then it stops working. There seems to be a beep generator node at 0x1a in this CODEC (ALC269_TYPE_ALC215) but it seems to be only connected to capture mixers at nodes 0x22 and 0x23. If I unmute the mixer input for 0x1a at node 0x23 and start recording from its "ALC285 Analog" capture device I can clearly hear beeps in that recording. So the beep generator is indeed working properly, however I wasn't able to figure out any way to connect it to speakers. However, the bits in the "Passthrough Control" register (0x36) seems to work at least partially: by zeroing "B" and "h" and setting "S" I can at least make the PIT PC speaker output appear either in this laptop speakers or headphones (depending on whether they are connected or not). There are some caveats, however: * If the CODEC gets runtime-suspended the beeps stop so it needs HDA beep device for keeping it awake during beeping. * If the beep generator node is generating any beep the PC beep passthrough seems to be temporarily inhibited, so the HDA beep device has to be prevented from using the actual beep generator node - but the beep device is still necessary due to the previous point. * In contrast with other platforms here beep amplification has to be disabled otherwise the beeps output are WAY louder than they were on pure BIOS setup. Unless someone (from Realtek probably) knows how to make the beep generator node output appear in speakers / headphones using PC beep passthrough seems to be the only way to make PC speaker beeping actually work on this platform. Signed-off-by: Maciej S. Szmigiero Acked-by: kailang@realtek.com Link: https://patch.msgid.link/7461f695b4daed80f2fc4b1463ead47f04f9ad05.1739741254.git.mail@maciej.szmigiero.name Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 592ba27580364c635b920eb7eae7d060e72b7aa1 Author: Saket Kumar Bhaskar Date: Mon Mar 3 14:54:51 2025 +0530 perf/hw_breakpoint: Return EOPNOTSUPP for unsupported breakpoint type [ Upstream commit 061c991697062f3bf87b72ed553d1d33a0e370dd ] Currently, __reserve_bp_slot() returns -ENOSPC for unsupported breakpoint types on the architecture. For example, powerpc does not support hardware instruction breakpoints. This causes the perf_skip BPF selftest to fail, as neither ENOENT nor EOPNOTSUPP is returned by perf_event_open for unsupported breakpoint types. As a result, the test that should be skipped for this arch is not correctly identified. To resolve this, hw_breakpoint_event_init() should exit early by checking for unsupported breakpoint types using hw_breakpoint_slots_cached() and return the appropriate error (-EOPNOTSUPP). Signed-off-by: Saket Kumar Bhaskar Signed-off-by: Ingo Molnar Cc: Marco Elver Cc: Dmitry Vyukov Cc: Ian Rogers Cc: Frederic Weisbecker Link: https://lore.kernel.org/r/20250303092451.1862862-1-skb99@linux.ibm.com Signed-off-by: Sasha Levin commit f9d15ef2e069d509c3de590270a3fed9b67417b0 Author: Peter Seiderer Date: Thu Feb 27 14:56:00 2025 +0100 net: pktgen: fix mpls maximum labels list parsing [ Upstream commit 2b15a0693f70d1e8119743ee89edbfb1271b3ea8 ] Fix mpls maximum labels list parsing up to MAX_MPLS_LABELS entries (instead of up to MAX_MPLS_LABELS - 1). Addresses the following: $ echo "mpls 00000f00,00000f01,00000f02,00000f03,00000f04,00000f05,00000f06,00000f07,00000f08,00000f09,00000f0a,00000f0b,00000f0c,00000f0d,00000f0e,00000f0f" > /proc/net/pktgen/lo\@0 -bash: echo: write error: Argument list too long Signed-off-by: Peter Seiderer Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8d7e13c31c52690655883dff604238b0760a3644 Author: Paul Elder Date: Fri Feb 28 18:17:31 2025 +0900 media: imx335: Set vblank immediately [ Upstream commit c0aa40f45fef80b4182704d1bc089cbf8ae8bed0 ] When the vblank v4l2 control is set, it does not get written to the hardware unless exposure is also changed. Change the behavior such that the vblank is written immediately when the control is set, as setting the vblank without changing the exposure is a valid use case (such as for changing the frame rate). Signed-off-by: Paul Elder Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 4176d6f2a67b81a2e261bff3833de73aa84862c6 Author: Yi Liu Date: Wed Feb 26 02:40:12 2025 -0800 iommufd: Disallow allocating nested parent domain with fault ID [ Upstream commit 1062d81086156e42878d701b816d2f368b53a77c ] Allocating a domain with a fault ID indicates that the domain is faultable. However, there is a gap for the nested parent domain to support PRI. Some hardware lacks the capability to distinguish whether PRI occurs at stage 1 or stage 2. This limitation may require software-based page table walking to resolve. Since no in-tree IOMMU driver currently supports this functionality, it is disallowed. For more details, refer to the related discussion at [1]. [1] https://lore.kernel.org/linux-iommu/bd1655c6-8b2f-4cfa-adb1-badc00d01811@intel.com/ Link: https://patch.msgid.link/r/20250226104012.82079-1-yi.l.liu@intel.com Suggested-by: Lu Baolu Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Reviewed-by: Lu Baolu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit af73c8fd7388df67be2bd721510f4f3853101fb4 Author: Uday Shankar Date: Fri Feb 28 21:31:48 2025 -0700 ublk: enforce ublks_max only for unprivileged devices [ Upstream commit 80bdfbb3545b6f16680a72c825063d08a6b44c7a ] Commit 403ebc877832 ("ublk_drv: add module parameter of ublks_max for limiting max allowed ublk dev"), claimed ublks_max was added to prevent a DoS situation with an untrusted user creating too many ublk devices. If that's the case, ublks_max should only restrict the number of unprivileged ublk devices in the system. Enforce the limit only for unprivileged ublk devices, and rename variables accordingly. Leave the external-facing parameter name unchanged, since changing it may break systems which use it (but still update its documentation to reflect its new meaning). As a result of this change, in a system where there are only normal (non-unprivileged) devices, the maximum number of such devices is increased to 1 << MINORBITS, or 1048576. That ought to be enough for anyone, right? Signed-off-by: Uday Shankar Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20250228-ublks_max-v1-1-04b7379190c0@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c4f025a58eef14983b424b95f7bafdc5602b79a2 Author: Jiasheng Jiang Date: Fri Feb 28 15:02:10 2025 +0000 dpll: Add an assertion to check freq_supported_num [ Upstream commit 39e912a959c19338855b768eaaee2917d7841f71 ] Since the driver is broken in the case that src->freq_supported is not NULL but src->freq_supported_num is 0, add an assertion for it. Signed-off-by: Jiasheng Jiang Reviewed-by: Jiri Pirko Reviewed-by: Vadim Fedorenko Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20250228150210.34404-1-jiashengjiangcool@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ebaed867bfd1ef1b56523b940cc1a437f74ef857 Author: Andrei Botila Date: Fri Feb 28 17:43:19 2025 +0200 net: phy: nxp-c45-tja11xx: add match_phy_device to TJA1103/TJA1104 [ Upstream commit a06a868a0cd96bc51401cdea897313a3f6ad01a0 ] Add .match_phy_device for the existing TJAs to differentiate between TJA1103 and TJA1104. TJA1103 and TJA1104 share the same PHY_ID but TJA1104 has MACsec capabilities while TJA1103 doesn't. Signed-off-by: Andrei Botila Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250228154320.2979000-2-andrei.botila@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94df9fd015acef4556fe16ce06092a8d597c8897 Author: Alexander Sverdlin Date: Mon Mar 3 08:46:57 2025 +0100 net: ethernet: ti: cpsw_new: populate netdev of_node [ Upstream commit 7ff1c88fc89688c27f773ba956f65f0c11367269 ] So that of_find_net_device_by_node() can find CPSW ports and other DSA switches can be stacked downstream. Tested in conjunction with KSZ8873. Reviewed-by: Siddharth Vadapalli Reviewed-by: Andrew Lunn Signed-off-by: Alexander Sverdlin Link: https://patch.msgid.link/20250303074703.1758297-1-alexander.sverdlin@siemens.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a4a834f2af5b51c01ff2303389b9673caa8630e Author: Paul E. McKenney Date: Thu Dec 12 14:15:07 2024 -0800 rcu: Fix get_state_synchronize_rcu_full() GP-start detection [ Upstream commit 85aad7cc417877054c65bd490dc037b087ef21b4 ] The get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full() functions use the root rcu_node structure's ->gp_seq field to detect the beginnings and ends of grace periods, respectively. This choice is necessary for the poll_state_synchronize_rcu_full() function because (give or take counter wrap), the following sequence is guaranteed not to trigger: get_state_synchronize_rcu_full(&rgos); synchronize_rcu(); WARN_ON_ONCE(!poll_state_synchronize_rcu_full(&rgos)); The RCU callbacks that awaken synchronize_rcu() instances are guaranteed not to be invoked before the root rcu_node structure's ->gp_seq field is updated to indicate the end of the grace period. However, these callbacks might start being invoked immediately thereafter, in particular, before rcu_state.gp_seq has been updated. Therefore, poll_state_synchronize_rcu_full() must refer to the root rcu_node structure's ->gp_seq field. Because this field is updated under this structure's ->lock, any code following a call to poll_state_synchronize_rcu_full() will be fully ordered after the full grace-period computation, as is required by RCU's memory-ordering semantics. By symmetry, the get_state_synchronize_rcu_full() function should also use this same root rcu_node structure's ->gp_seq field. But it turns out that symmetry is profoundly (though extremely infrequently) destructive in this case. To see this, consider the following sequence of events: 1. CPU 0 starts a new grace period, and updates rcu_state.gp_seq accordingly. 2. As its first step of grace-period initialization, CPU 0 examines the current CPU hotplug state and decides that it need not wait for CPU 1, which is currently offline. 3. CPU 1 comes online, and updates its state. But this does not affect the current grace period, but rather the one after that. After all, CPU 1 was offline when the current grace period started, so all pre-existing RCU readers on CPU 1 must have completed or been preempted before it last went offline. The current grace period therefore has nothing it needs to wait for on CPU 1. 4. CPU 1 switches to an rcutorture kthread which is running rcutorture's rcu_torture_reader() function, which starts a new RCU reader. 5. CPU 2 is running rcutorture's rcu_torture_writer() function and collects a new polled grace-period "cookie" using get_state_synchronize_rcu_full(). Because the newly started grace period has not completed initialization, the root rcu_node structure's ->gp_seq field has not yet been updated to indicate that this new grace period has already started. This cookie is therefore set up for the end of the current grace period (rather than the end of the following grace period). 6. CPU 0 finishes grace-period initialization. 7. If CPU 1’s rcutorture reader is preempted, it will be added to the ->blkd_tasks list, but because CPU 1’s ->qsmask bit is not set in CPU 1's leaf rcu_node structure, the ->gp_tasks pointer will not be updated.  Thus, this grace period will not wait on it.  Which is only fair, given that the CPU did not come online until after the grace period officially started. 8. CPUs 0 and 2 then detect the new grace period and then report a quiescent state to the RCU core. 9. Because CPU 1 was offline at the start of the current grace period, CPUs 0 and 2 are the only CPUs that this grace period needs to wait on. So the grace period ends and post-grace-period cleanup starts. In particular, the root rcu_node structure's ->gp_seq field is updated to indicate that this grace period has now ended. 10. CPU 2 continues running rcu_torture_writer() and sees that, from the viewpoint of the root rcu_node structure consulted by the poll_state_synchronize_rcu_full() function, the grace period has ended.  It therefore updates state accordingly. 11. CPU 1 is still running the same RCU reader, which notices this update and thus complains about the too-short grace period. The fix is for the get_state_synchronize_rcu_full() function to use rcu_state.gp_seq instead of the root rcu_node structure's ->gp_seq field. With this change in place, if step 5's cookie indicates that the grace period has not yet started, then any prior code executed by CPU 2 must have happened before CPU 1 came online. This will in turn prevent CPU 1's code in steps 3 and 11 from spanning CPU 2's grace-period wait, thus preventing CPU 1 from being subjected to a too-short grace period. This commit therefore makes this change. Note that there is no change to the poll_state_synchronize_rcu_full() function, which as noted above, must continue to use the root rcu_node structure's ->gp_seq field. This is of course an asymmetry between these two functions, but is an asymmetry that is absolutely required for correct operation. It is a common human tendency to greatly value symmetry, and sometimes symmetry is a wonderful thing. Other times, symmetry results in poor performance. But in this case, symmetry is just plain wrong. Nevertheless, the asymmetry does require an additional adjustment. It is possible for get_state_synchronize_rcu_full() to see a given grace period as having started, but for an immediately following poll_state_synchronize_rcu_full() to see it as having not yet started. Given the current rcu_seq_done_exact() implementation, this will result in a false-positive indication that the grace period is done from poll_state_synchronize_rcu_full(). This is dealt with by making rcu_seq_done_exact() reach back three grace periods rather than just two of them. However, simply changing get_state_synchronize_rcu_full() function to use rcu_state.gp_seq instead of the root rcu_node structure's ->gp_seq field results in a theoretical bug in kernels booted with rcutree.rcu_normal_wake_from_gp=1 due to the following sequence of events: o The rcu_gp_init() function invokes rcu_seq_start() to officially start a new grace period. o A new RCU reader begins, referencing X from some RCU-protected list. The new grace period is not obligated to wait for this reader. o An updater removes X, then calls synchronize_rcu(), which queues a wait element. o The grace period ends, awakening the updater, which frees X while the reader is still referencing it. The reason that this is theoretical is that although the grace period has officially started, none of the CPUs are officially aware of this, and thus will have to assume that the RCU reader pre-dated the start of the grace period. Detailed explanation can be found at [2] and [3]. Except for kernels built with CONFIG_PROVE_RCU=y, which use the polled grace-period APIs, which can and do complain bitterly when this sequence of events occurs. Not only that, there might be some future RCU grace-period mechanism that pulls this sequence of events from theory into practice. This commit therefore also pulls the call to rcu_sr_normal_gp_init() to precede that to rcu_seq_start(). Although this fixes commit 91a967fd6934 ("rcu: Add full-sized polling for get_completed*() and poll_state*()"), it is not clear that it is worth backporting this commit. First, it took me many weeks to convince rcutorture to reproduce this more frequently than once per year. Second, this cannot be reproduced at all without frequent CPU-hotplug operations, as in waiting all of 50 milliseconds from the end of the previous operation until starting the next one. Third, the TREE03.boot settings cause multi-millisecond delays during RCU grace-period initialization, which greatly increase the probability of the above sequence of events. (Don't do this in production workloads!) Fourth, the TREE03 rcutorture scenario was modified to use four-CPU guest OSes, to have a single-rcu_node combining tree, no testing of RCU priority boosting, and no random preemption, and these modifications were necessary to reproduce this issue in a reasonable timeframe. Fifth, extremely heavy use of get_state_synchronize_rcu_full() and/or poll_state_synchronize_rcu_full() is required to reproduce this, and as of v6.12, only kfree_rcu() uses it, and even then not particularly heavily. [boqun: Apply the fix [1], and add the comment before the moved rcu_sr_normal_gp_init(). Additional links are added for explanation.] Signed-off-by: Paul E. McKenney Reviewed-by: Frederic Weisbecker Reviewed-by: Joel Fernandes (Google) Tested-by: Uladzislau Rezki (Sony) Link: https://lore.kernel.org/rcu/d90bd6d9-d15c-4b9b-8a69-95336e74e8f4@paulmck-laptop/ [1] Link: https://lore.kernel.org/rcu/20250303001507.GA3994772@joelnvbox/ [2] Link: https://lore.kernel.org/rcu/Z8bcUsZ9IpRi1QoP@pc636/ [3] Reviewed-by: Joel Fernandes Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin commit 5aba8ac434d8bcffc673538da6772ec955a81b3f Author: Artur Weber Date: Mon Mar 3 21:54:47 2025 +0100 pinctrl: bcm281xx: Use "unsigned int" instead of bare "unsigned" [ Upstream commit 07b5a2a13f4704c5eae3be7277ec54ffdba45f72 ] Replace uses of bare "unsigned" with "unsigned int" to fix checkpatch warnings. No functional change. Signed-off-by: Artur Weber Link: https://lore.kernel.org/20250303-bcm21664-pinctrl-v3-2-5f8b80e4ab51@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4731d5328f507ae8fd8a57abbca9119ec7a8d665 Author: Hans Verkuil Date: Mon Feb 24 14:13:24 2025 +0100 media: cx231xx: set device_caps for 417 [ Upstream commit a79efc44b51432490538a55b9753a721f7d3ea42 ] The video_device for the MPEG encoder did not set device_caps. Add this, otherwise the video device can't be registered (you get a WARN_ON instead). Not seen before since currently 417 support is disabled, but I found this while experimenting with it. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f29c876d72d71b64b0cf0958345f1da0fbd9c383 Author: Peter Zijlstra Date: Wed Feb 5 11:21:28 2025 +0100 perf/core: Clean up perf_try_init_event() [ Upstream commit da02f54e81db2f7bf6af9d1d0cfc5b41ec6d0dcb ] Make sure that perf_try_init_event() doesn't leave event->pmu nor event->destroy set on failure. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Acked-by: Ravi Bangoria Link: https://lore.kernel.org/r/20250205102449.110145835@infradead.org Signed-off-by: Sasha Levin commit cc714c89ef5a990bc2c3b96171980f06b196e0b7 Author: Aric Cyr Date: Thu Jan 23 16:39:52 2025 -0500 drm/amd/display: Request HW cursor on DCN3.2 with SubVP [ Upstream commit b74f46f3ce1e5f6336645f1e9ff47c56d5dfdef1 ] [why] When SubVP is active the HW cursor size is limited to 64x64, and anything larger will force composition which is bad for gaming on DCN3.2 if the game uses a larger cursor. [how] If HW cursor is requested, typically by a fullscreen game, do not enable SubVP so that up to 256x256 cursor sizes are available for DCN3.2. Reviewed-by: Aric Cyr Signed-off-by: Aric Cyr Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1f2b3ea00717f867d8a7e263fc94fd2b9b4f22f1 Author: Dillon Varone Date: Wed Feb 12 17:06:42 2025 -0500 drm/amd/display: Fix p-state type when p-state is unsupported [ Upstream commit a025f424af0407b7561bd5e6217295dde3abbc2e ] [WHY&HOW] P-state type would remain on previously used when unsupported which causes confusion in logging and visual confirm, so set back to zero when unsupported. Reviewed-by: Aric Cyr Signed-off-by: Dillon Varone Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e015cef8b78f6020bb43f898aa4e543a166d3aff Author: Dillon Varone Date: Thu Feb 13 13:10:41 2025 -0500 drm/amd/display: Fix DMUB reset sequence for DCN401 [ Upstream commit 0dfcc2bf269010a6e093793034c048049a40ee93 ] [WHY] It should no longer use DMCUB_SOFT_RESET as it can result in the memory request path becoming desynchronized. [HOW] To ensure robustness in the reset sequence: 1) Extend timeout on the "halt" command sent via gpint, and check for controller to enter "wait" as a stronger guarantee that there are no requests to memory still in flight. 2) Remove usage of DMCUB_SOFT_RESET 3) Rely on PSP to reset the controller safely Reviewed-by: Nicholas Kazlauskas Signed-off-by: Dillon Varone Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 682c4226f317ec1954755eb4e8e58dd4d3a5cef1 Author: George Shen Date: Fri Feb 14 22:00:13 2025 -0500 drm/amd/display: Skip checking FRL_MODE bit for PCON BW determination [ Upstream commit 0584bbcf0c53c133081100e4f4c9fe41e598d045 ] [Why/How] Certain PCON will clear the FRL_MODE bit despite supporting the link BW indicated in the other bits. Thus, skip checking the FRL_MODE bit when interpreting the hdmi_encoded_link_bw struct. Reviewed-by: Wenjing Liu Signed-off-by: George Shen Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5bf0fd2bd5efba63f278b5b6fca7a1ddead451be Author: Nicholas Kazlauskas Date: Wed Feb 19 09:56:53 2025 -0500 drm/amd/display: Ensure DMCUB idle before reset on DCN31/DCN35 [ Upstream commit c707ea82c79dbd1d295ec94cc6529a5248c77757 ] [Why] If we soft reset before halt finishes and there are outstanding memory transactions then the memory interface may produce unexpected results, such as out of order transactions when the firmware next runs. These can manifest as random or unexpected load/store violations. [How] Increase the timeout before soft reset to ensure the DMCUB has quiesced. This is effectively 1s maximum based on experimentation. Use the enable bit check on DCN31 like we're doing on DCN35 and reorder the reset writes to follow the HW programming guide. Ensure we're reading SCRATCH7 instead of SCRATCH8 for the HALT code. No current versions of DMCUB firmware use the SCRATCH8 boot bit to dynamically switch where the HALT code goes to maintain backwards compatibility with PSP. Reviewed-by: Dillon Varone Signed-off-by: Nicholas Kazlauskas Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a23f3910123b518c8cf0fbb89aa9c9e08d23a4ca Author: Victor Lu Date: Thu Feb 13 18:38:28 2025 -0500 drm/amdgpu: Do not program AGP BAR regs under SRIOV in gfxhub_v1_0.c [ Upstream commit 057fef20b8401110a7bc1c2fe9d804a8a0bf0d24 ] SRIOV VF does not have write access to AGP BAR regs. Skip the writes to avoid a dmesg warning. Signed-off-by: Victor Lu Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 69bb5b3ae348040e385113efba5bdc76396644d0 Author: Matti Lehtimäki Date: Thu Feb 6 20:56:48 2025 +0100 remoteproc: qcom_wcnss: Handle platforms with only single power domain [ Upstream commit 65991ea8a6d1e68effdc01d95ebe39f1653f7b71 ] Both MSM8974 and MSM8226 have only CX as power domain with MX & PX being handled as regulators. Handle this case by reodering pd_names to have CX first, and handling that the driver core will already attach a single power domain internally. Signed-off-by: Matti Lehtimäki [luca: minor changes] Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20250206-wcnss-singlepd-v2-2-9a53ee953dee@lucaweiss.eu [bjorn: Added missing braces to else after multi-statement if] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 95080412e9304cb5eeadd8a1f54aae9465330c54 Author: Ming Lei Date: Wed Mar 5 12:31:20 2025 +0800 blk-throttle: don't take carryover for prioritized processing of metadata [ Upstream commit a9fc8868b350cbf4ff730a4ea9651319cc669516 ] Commit 29390bb5661d ("blk-throttle: support prioritized processing of metadata") takes bytes/ios carryover for prioritized processing of metadata. Turns out we can support it by charging it directly without trimming slice, and the result is same with carryover. Cc: Tejun Heo Cc: Josef Bacik Cc: Yu Kuai Signed-off-by: Ming Lei Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20250305043123.3938491-3-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c4525b513de399109fc51529fcf7fec04f907be1 Author: Choong Yong Liang Date: Thu Feb 27 20:15:17 2025 +0800 net: phylink: use pl->link_interface in phylink_expects_phy() [ Upstream commit b63263555eaafbf9ab1a82f2020bbee872d83759 ] The phylink_expects_phy() function allows MAC drivers to check if they are expecting a PHY to attach. The checking condition in phylink_expects_phy() aims to achieve the same result as the checking condition in phylink_attach_phy(). However, the checking condition in phylink_expects_phy() uses pl->link_config.interface, while phylink_attach_phy() uses pl->link_interface. Initially, both pl->link_interface and pl->link_config.interface are set to SGMII, and pl->cfg_link_an_mode is set to MLO_AN_INBAND. When the interface switches from SGMII to 2500BASE-X, pl->link_config.interface is updated by phylink_major_config(). At this point, pl->cfg_link_an_mode remains MLO_AN_INBAND, and pl->link_config.interface is set to 2500BASE-X. Subsequently, when the STMMAC interface is taken down administratively and brought back up, it is blocked by phylink_expects_phy(). Since phylink_expects_phy() and phylink_attach_phy() aim to achieve the same result, phylink_expects_phy() should check pl->link_interface, which never changes, instead of pl->link_config.interface, which is updated by phylink_major_config(). Reviewed-by: Russell King (Oracle) Signed-off-by: Choong Yong Liang Link: https://patch.msgid.link/20250227121522.1802832-2-yong.liang.choong@linux.intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93f581d7634ffca6823cfedcdb737bd31f810612 Author: Thomas Zimmermann Date: Wed Feb 26 18:03:04 2025 +0100 drm/gem: Test for imported GEM buffers with helper [ Upstream commit b57aa47d39e94dc47403a745e2024664e544078c ] Add drm_gem_is_imported() that tests if a GEM object's buffer has been imported. Update the GEM code accordingly. GEM code usually tests for imports if import_attach has been set in struct drm_gem_object. But attaching a dma-buf on import requires a DMA-capable importer device, which is not the case for many serial busses like USB or I2C. The new helper tests if a GEM object's dma-buf has been created from the GEM object. Signed-off-by: Thomas Zimmermann Reviewed-by: Anusha Srivatsa Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20250226172457.217725-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit cd918ec24168fe08c6aafc077dd3b6d88364c5cf Author: Matthew Wilcox (Oracle) Date: Wed Mar 5 20:47:25 2025 +0000 orangefs: Do not truncate file size [ Upstream commit 062e8093592fb866b8e016641a8b27feb6ac509d ] 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems. Signed-off-by: "Matthew Wilcox (Oracle)" Link: https://lore.kernel.org/r/20250305204734.1475264-2-willy@infradead.org Tested-by: Mike Marshall Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 6ad0673ab24f0b94f396bfafb899d299613e6e33 Author: AngeloGioacchino Del Regno Date: Wed Feb 12 11:00:05 2025 +0100 soc: mediatek: mtk-mutex: Add DPI1 SOF/EOF to MT8188 mutex tables [ Upstream commit 694e0b7c1747603243da874de9cbbf8cb806ca44 ] MT8188 uses DPI1 to output to the HDMI controller: add the Start of Frame and End of Frame configuration for the DPI1 IP to the tables to unblock generation and sending of these signals to the GCE. Link: https://lore.kernel.org/r/20250212100012.33001-2-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit cc80a5cc520939d0a7d071cc4ae4b3c55ef171d0 Author: Ming-Hung Tsai Date: Thu Mar 6 16:41:50 2025 +0800 dm cache: prevent BUG_ON by blocking retries on failed device resumes [ Upstream commit 5da692e2262b8f81993baa9592f57d12c2703dea ] A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object. Reproduce steps: 1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata. cat <> cmeta.xml EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache 4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings. dmsetup resume cache Kernel logs: (snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Fix by disallowing resume operations for devices that failed the initial attempt. Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 1c171908807cb3717c7a38e51363d1fb8e887e13 Author: Niklas Neronin Date: Thu Mar 6 16:49:48 2025 +0200 usb: xhci: set page size to the xHCI-supported size [ Upstream commit 68c1f1671650b49bbd26e6a65ddcf33f2565efa3 ] The current xHCI driver does not validate whether a page size of 4096 bytes is supported. Address the issue by setting the page size to the value supported by the xHCI controller, as read from the Page Size register. In the event of an unexpected value; default to a 4K page size. Additionally, this commit removes unnecessary debug messages and instead prints the supported and used page size once. The xHCI controller supports page sizes of (2^{(n+12)}) bytes, where 'n' is the Page Size Bit. Only one page size is supported, with a maximum page size of 128 KB. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5520fed18df866d7821fbde9549c6cb7beb096ee Author: Markus Elfring Date: Fri Oct 4 15:50:15 2024 +0200 media: c8sectpfe: Call of_node_put(i2c_bus) only once in c8sectpfe_probe() [ Upstream commit b773530a34df0687020520015057075f8b7b4ac4 ] An of_node_put(i2c_bus) call was immediately used after a pointer check for an of_find_i2c_adapter_by_node() call in this function implementation. Thus call such a function only once instead directly before the check. This issue was transformed by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 25056d1fe57eb6d332991820dbc3d2a65303e7c3 Author: Svyatoslav Ryhel Date: Wed Feb 26 12:56:11 2025 +0200 ARM: tegra: Switch DSI-B clock parent to PLLD on Tegra114 [ Upstream commit 2b3db788f2f614b875b257cdb079adadedc060f3 ] PLLD is usually used as parent clock for internal video devices, like DSI for example, while PLLD2 is used as parent for HDMI. Signed-off-by: Svyatoslav Ryhel Link: https://lore.kernel.org/r/20250226105615.61087-3-clamor95@gmail.com Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 8fc16414c3ef7b7db4e8873557316dbaeb36f747 Author: Arnd Bergmann Date: Wed Mar 5 22:14:02 2025 +0100 soc: samsung: include linux/array_size.h where needed [ Upstream commit 4c57930f68d90e0d52c396d058cfa9ed8447a6c4 ] This does not necessarily get included through asm/io.h: drivers/soc/samsung/exynos3250-pmu.c:120:18: error: use of undeclared identifier 'ARRAY_SIZE' 120 | for (i = 0; i < ARRAY_SIZE(exynos3250_list_feed); i++) { | ^ drivers/soc/samsung/exynos5250-pmu.c:162:18: error: use of undeclared identifier 'ARRAY_SIZE' 162 | for (i = 0; i < ARRAY_SIZE(exynos5_list_both_cnt_feed); i++) { | ^ Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250305211446.43772-1-arnd@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 4943c0bae1248fa69fba0872ebb6012d805f4c26 Author: Matthew Brost Date: Wed Mar 5 17:26:26 2025 -0800 drm/xe: Retry BO allocation [ Upstream commit 1d724a2f1b2c3f0cba4975784a808482e0631adf ] TTM doesn't support fair eviction via WW locking, this mitigated in by using retry loops in exec and preempt rebind worker. Extend this retry loop to BO allocation. Once TTM supports fair eviction this patch can be reverted. v4: - Keep line break (Stuart) Signed-off-by: Matthew Brost Reviewed-by: Gwan-gyeong Mun Reviewed-by: Stuart Summers Link: https://patchwork.freedesktop.org/patch/msgid/20250306012657.3505757-2-matthew.brost@intel.com Signed-off-by: Sasha Levin commit 623669ae7a8204264098c80cdc13086b7371bacf Author: Matthew Brost Date: Wed Mar 5 17:26:36 2025 -0800 drm/xe: Nuke VM's mapping upon close [ Upstream commit 074e40d9c2a84939fe28d7121d3469db50f34a3d ] Clear root PT entry and invalidate entire VM's address space when closing the VM. Will prevent the GPU from accessing any of the VM's memory after closing. v2: - s/vma/vm in kernel doc (CI) - Don't nuke migration VM as this occur at driver unload (CI) v3: - Rebase and pull into SVM series (Thomas) - Wait for pending binds (Thomas) v5: - Remove xe_gt_tlb_invalidation_fence_fini in error case (Matt Auld) - Drop local migration bool (Thomas) v7: - Add drm_dev_enter/exit protecting invalidation (CI, Matt Auld) Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20250306012657.3505757-12-matthew.brost@intel.com Signed-off-by: Sasha Levin commit a3642d2d73a97b39c50fcb6abb71c2488cda21ae Author: Andy Shevchenko Date: Wed Mar 5 12:55:34 2025 +0200 ieee802154: ca8210: Use proper setters and getters for bitwise types [ Upstream commit 169b2262205836a5d1213ff44dca2962276bece1 ] Sparse complains that the driver doesn't respect the bitwise types: drivers/net/ieee802154/ca8210.c:1796:27: warning: incorrect type in assignment (different base types) drivers/net/ieee802154/ca8210.c:1796:27: expected restricted __le16 [addressable] [assigned] [usertype] pan_id drivers/net/ieee802154/ca8210.c:1796:27: got unsigned short [usertype] drivers/net/ieee802154/ca8210.c:1801:25: warning: incorrect type in assignment (different base types) drivers/net/ieee802154/ca8210.c:1801:25: expected restricted __le16 [addressable] [assigned] [usertype] pan_id drivers/net/ieee802154/ca8210.c:1801:25: got unsigned short [usertype] drivers/net/ieee802154/ca8210.c:1928:28: warning: incorrect type in argument 3 (different base types) drivers/net/ieee802154/ca8210.c:1928:28: expected unsigned short [usertype] dst_pan_id drivers/net/ieee802154/ca8210.c:1928:28: got restricted __le16 [addressable] [usertype] pan_id Use proper setters and getters for bitwise types. Note, in accordance with [1] the protocol is little endian. Link: https://www.cascoda.com/wp-content/uploads/2018/11/CA-8210_datasheet_0418.pdf [1] Reviewed-by: Miquel Raynal Reviewed-by: Linus Walleij Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/20250305105656.2133487-2-andriy.shevchenko@linux.intel.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 3afa1610e5a4e50f9d87cb3460a4d02c7c14fad0 Author: Alexandre Belloni Date: Mon Mar 3 23:37:44 2025 +0100 rtc: ds1307: stop disabling alarms on probe [ Upstream commit dcec12617ee61beed928e889607bf37e145bf86b ] It is a bad practice to disable alarms on probe or remove as this will prevent alarms across reboots. Link: https://lore.kernel.org/r/20250303223744.1135672-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 73d01bcbf2aad43c1855e7b45fd2f64bd1583ce4 Author: Eric Dumazet Date: Wed Mar 5 13:05:50 2025 +0000 tcp: bring back NUMA dispersion in inet_ehash_locks_alloc() [ Upstream commit f8ece40786c9342249aa0a1b55e148ee23b2a746 ] We have platforms with 6 NUMA nodes and 480 cpus. inet_ehash_locks_alloc() currently allocates a single 64KB page to hold all ehash spinlocks. This adds more pressure on a single node. Change inet_ehash_locks_alloc() to use vmalloc() to spread the spinlocks on all online nodes, driven by NUMA policies. At boot time, NUMA policy is interleave=all, meaning that tcp_hashinfo.ehash_locks gets hash dispersion on all nodes. Tested: lack5:~# grep inet_ehash_locks_alloc /proc/vmallocinfo 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2 lack5:~# echo 8192 >/proc/sys/net/ipv4/tcp_child_ehash_entries lack5:~# numactl --interleave=all unshare -n bash -c "grep inet_ehash_locks_alloc /proc/vmallocinfo" 0x000000004e99d30c-0x00000000763f3279 36864 inet_ehash_locks_alloc+0x90/0x100 pages=8 vmalloc N0=1 N1=2 N2=2 N3=1 N4=1 N5=1 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2 lack5:~# numactl --interleave=0,5 unshare -n bash -c "grep inet_ehash_locks_alloc /proc/vmallocinfo" 0x00000000fd73a33e-0x0000000004b9a177 36864 inet_ehash_locks_alloc+0x90/0x100 pages=8 vmalloc N0=4 N5=4 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2 lack5:~# echo 1024 >/proc/sys/net/ipv4/tcp_child_ehash_entries lack5:~# numactl --interleave=all unshare -n bash -c "grep inet_ehash_locks_alloc /proc/vmallocinfo" 0x00000000db07d7a2-0x00000000ad697d29 8192 inet_ehash_locks_alloc+0x90/0x100 pages=1 vmalloc N2=1 0x00000000d9aec4d1-0x00000000a828b652 69632 inet_ehash_locks_alloc+0x90/0x100 pages=16 vmalloc N0=2 N1=3 N2=3 N3=3 N4=3 N5=2 Signed-off-by: Eric Dumazet Tested-by: Jason Xing Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250305130550.1865988-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a06861298554bbd46611fcda86f86529867afd0d Author: Takashi Iwai Date: Fri Mar 7 09:42:42 2025 +0100 ALSA: seq: Improve data consistency at polling [ Upstream commit e3cd33ab17c33bd8f1a9df66ec83a15dd8f7afbb ] snd_seq_poll() calls snd_seq_write_pool_allocated() that reads out a field in client->pool object, while it can be updated concurrently via ioctls, as reported by syzbot. The data race itself is harmless, as it's merely a poll() call, and the state is volatile. OTOH, the read out of poll object info from the caller side is fragile, and we can leave it better in snd_seq_pool_poll_wait() alone. A similar pattern is seen in snd_seq_kernel_client_write_poll(), too, which is called from the OSS sequencer. This patch drops the pool checks from the caller side and add the pool->lock in snd_seq_pool_poll_wait() for better data consistency. Reported-by: syzbot+2d373c9936c00d7e120c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/67c88903.050a0220.15b4b9.0028.GAE@google.com Link: https://patch.msgid.link/20250307084246.29271-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 515a21a5e19abd7363774df1f98ad74431cac6f1 Author: Andreas Schwab Date: Mon Jan 13 18:19:09 2025 +0100 powerpc/prom_init: Fixup missing #size-cells on PowerBook6,7 [ Upstream commit 7e67ef889c9ab7246547db73d524459f47403a77 ] Similar to the PowerMac3,1, the PowerBook6,7 is missing the #size-cells property on the i2s node. Depends-on: commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling") Signed-off-by: Andreas Schwab Acked-by: Rob Herring (Arm) [maddy: added "commit" work in depends-on to avoid checkpatch error] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/875xmizl6a.fsf@igel.home Signed-off-by: Sasha Levin commit 09193145d11801053cb37910fe7d1ccec3f2f0e5 Author: Jon Hunter Date: Thu Jan 16 15:19:03 2025 +0000 arm64: tegra: Resize aperture for the IGX PCIe C5 slot [ Upstream commit 6d4bfe6d86af1ef52bdb4592c9afb2037f24f2c4 ] Some discrete graphics cards such as the NVIDIA RTX A6000 support resizable BARs. When connecting an A6000 card to the NVIDIA IGX Orin platform, resizing the BAR1 aperture to 8GB fails because the current device-tree configuration for the PCIe C5 slot cannot support this. Fix this by updating the device-tree 'reg' and 'ranges' properties for the PCIe C5 slot to support this. Signed-off-by: Jon Hunter Link: https://lore.kernel.org/r/20250116151903.476047-1-jonathanh@nvidia.com Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 2f0044e20fab1de422f3abb39788aebeb932a5a6 Author: Diogo Ivo Date: Mon Feb 24 12:17:36 2025 +0000 arm64: tegra: p2597: Fix gpio for vdd-1v8-dis regulator [ Upstream commit f34621f31e3be81456c903287f7e4c0609829e29 ] According to the board schematics the enable pin of this regulator is connected to gpio line #9 of the first instance of the TCA9539 GPIO expander, so adjust it. Signed-off-by: Diogo Ivo Link: https://lore.kernel.org/r/20250224-diogo-gpio_exp-v1-1-80fb84ac48c6@tecnico.ulisboa.pt Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ecaa856227ae44f6b9323adb2e84bb9445632bdb Author: Emily Deng Date: Mon Mar 3 15:10:22 2025 +0800 drm/amdgpu: Fix missing drain retry fault the last entry [ Upstream commit fe2fa3be3d59ba67d6de54a0064441ec233cb50c ] While the entry get in svm_range_unmap_from_cpu is the last entry, and the entry is page fault, it also need to be dropped. So for equal case, it also need to be dropped. v2: Only modify the svm_range_restore_pages. Signed-off-by: Emily Deng Reviewed-by: Xiaogang Chen Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c700730d816d660aa48c89e926f9b8678f25b472 Author: Harish Kasiviswanathan Date: Tue Jan 14 14:07:24 2025 -0500 drm/amdkfd: Set per-process flags only once cik/vi [ Upstream commit 289e68503a4533b014f8447e2af28ad44c92c221 ] Set per-process static sh_mem config only once during process initialization. Move all static changes from update_qpd() which is called each time a queue is created to set_cache_memory_policy() which is called once during process initialization. set_cache_memory_policy() is currently defined only for cik and vi family. So this commit only focuses on these two. A separate commit will address other asics. Signed-off-by: Harish Kasiviswanathan Reviewed-by: Amber Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e1901e8e6bbc44b9c91b55ce47deb9297cd7bb8d Author: Harish Kasiviswanathan Date: Tue Jan 14 14:13:35 2025 -0500 drm/amdkfd: Set per-process flags only once for gfx9/10/11/12 [ Upstream commit 61972cd93af70738a6ad7f93e17cc7f68a01e182 ] Define set_cache_memory_policy() for these asics and move all static changes from update_qpd() which is called each time a queue is created to set_cache_memory_policy() which is called once during process initialization Signed-off-by: Harish Kasiviswanathan Reviewed-by: Amber Lin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6a1706dfe0569a3d1934012948a4c1f420b5562f Author: Sven Schwermer Date: Mon Feb 24 08:42:25 2025 +0100 crypto: mxs-dcp - Only set OTP_KEY bit for OTP key [ Upstream commit caa9dbb76ff52ec848a57245062aaeaa07740adc ] While MXS_DCP_CONTROL0_OTP_KEY is set, the CRYPTO_KEY (DCP_PAES_KEY_OTP) is used even if the UNIQUE_KEY (DCP_PAES_KEY_UNIQUE) is selected. This is not clearly documented, but this implementation is consistent with NXP's downstream kernel fork and optee_os. Signed-off-by: Sven Schwermer Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7caad075acb634a74911830d6386c50ea12566cd Author: Herbert Xu Date: Thu Feb 27 17:04:46 2025 +0800 crypto: lzo - Fix compression buffer overrun [ Upstream commit cc47f07234f72cbd8e2c973cdbf2a6730660a463 ] Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller. Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo. Signed-off-by: Herbert Xu Reviewed-by: David Sterba Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f615e8d2dec6746127d4667c3cae81bfd6a1ed3a Author: Niklas Cassel Date: Thu Jan 23 13:01:48 2025 +0100 misc: pci_endpoint_test: Give disabled BARs a distinct error code [ Upstream commit 7e80bbef1d697dbce7a39cfad0df770880fe3f29 ] The current code returns -ENOMEM if test->bar[barno] is NULL. There can be two reasons why test->bar[barno] is NULL: 1) The pci_ioremap_bar() call in pci_endpoint_test_probe() failed. 2) The BAR was skipped, because it is disabled by the endpoint. Many PCI endpoint controller drivers will disable all BARs in their init function. A disabled BAR will have a size of 0. A PCI endpoint function driver will be able to enable any BAR that is not marked as BAR_RESERVED (which means that the BAR should not be touched by the EPF driver). Thus, perform check if the size is 0, before checking if test->bar[barno] is NULL, such that we can return different errors. This will allow the selftests to return SKIP instead of FAIL for disabled BARs. Signed-off-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250123120147.3603409-3-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit fe2329eff5bee461ebcafadb6ca1df0cbf5945fd Author: Christian Bruel Date: Fri Jan 24 13:30:43 2025 +0100 PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops [ Upstream commit 934e9d137d937706004c325fa1474f9e3f1ba10a ] Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. Reviewed-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Signed-off-by: Christian Bruel Link: https://lore.kernel.org/r/20250124123043.96112-1-christian.bruel@foss.st.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 1e0398a349e85cc1a23bafcf005c9a351251267f Author: Chin-Ting Kuo Date: Mon Jan 13 17:37:37 2025 +0800 watchdog: aspeed: Update bootstatus handling [ Upstream commit 5c03f9f4d36292150c14ebd90788c4d3273ed9dc ] The boot status in the watchdog device struct is updated during controller probe stage. Application layer can get the boot status through the command, cat /sys/class/watchdog/watchdogX/bootstatus. The bootstatus can be, WDIOF_CARDRESET => System is reset due to WDT timeout occurs. Others => Other reset events, e.g., power on reset. On ASPEED platforms, boot status is recorded in the SCU registers. - AST2400: Only a bit is used to represent system reset triggered by any WDT controller. - AST2500/AST2600: System reset triggered by different WDT controllers can be distinguished by different SCU bits. Besides, on AST2400 and AST2500, since alternating boot event is also triggered by using WDT timeout mechanism, it is classified as WDIOF_CARDRESET. Signed-off-by: Chin-Ting Kuo Reviewed-by: Andrew Jeffery Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20250113093737.845097-2-chin-ting_kuo@aspeedtech.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit d95fdee2253e612216e72f29c65b92ec42d254eb Author: Aaron Kling Date: Mon Mar 10 00:28:48 2025 -0500 cpufreq: tegra186: Share policy per cluster [ Upstream commit be4ae8c19492cd6d5de61ccb34ffb3f5ede5eec8 ] This functionally brings tegra186 in line with tegra210 and tegra194, sharing a cpufreq policy between all cores in a cluster. Reviewed-by: Sumit Gupta Acked-by: Thierry Reding Signed-off-by: Aaron Kling Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 11be3d3f956ba13cd91d41655e5046a6084e8083 Author: Vasant Hegde Date: Thu Feb 27 16:23:16 2025 +0000 iommu/amd/pgtbl_v2: Improve error handling [ Upstream commit 36a1cfd497435ba5e37572fe9463bb62a7b1b984 ] Return -ENOMEM if v2_alloc_pte() fails to allocate memory. Signed-off-by: Vasant Hegde Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20250227162320.5805-4-vasant.hegde@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9032252905664bb033eb9bb8acb6e8a04f31cf39 Author: Yeoreum Yun Date: Thu Mar 6 12:11:06 2025 +0000 coresight-etb10: change etb_drvdata spinlock's type to raw_spinlock_t [ Upstream commit 6b80c0abe475ed1017c5e862636049aa1cc17a1a ] In coresight-etb10 drivers, etb_drvdata->spinlock can be held during __schedule() by perf_event_task_sched_out()/in(). Since etb_drvdata->spinlock type is spinlock_t and perf_event_task_sched_out()/in() is called after acquiring rq_lock, which is raw_spinlock_t (an unsleepable lock), this poses an issue in PREEMPT_RT kernel where spinlock_t is sleepable. To address this, change type etb_drvdata->spinlock in coresight-etb10 drivers, which can be called by perf_event_task_sched_out()/in(), from spinlock_t to raw_spinlock_t. Reviewed-by: James Clark Reviewed-by: Mike Leach Signed-off-by: Yeoreum Yun Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250306121110.1647948-6-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 75ae2a35536111c557952f809323e5fe1674aa09 Author: Coly Li Date: Sun Mar 9 12:05:56 2025 -0400 badblocks: Fix a nonsense WARN_ON() which checks whether a u64 variable < 0 [ Upstream commit 7e76336e14de9a2b67af96012ddd46c5676cf340 ] In _badblocks_check(), there are lines of code like this, 1246 sectors -= len; [snipped] 1251 WARN_ON(sectors < 0); The WARN_ON() at line 1257 doesn't make sense because sectors is unsigned long long type and never to be <0. Fix it by checking directly checking whether sectors is less than len. Reported-by: Dan Carpenter Signed-off-by: Coly Li Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20250309160556.42854-1-colyli@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7bd6061b0a44b924d7c3e2525662c1bb0c6ce400 Author: Alexey Klimov Date: Fri Feb 28 16:14:30 2025 +0000 ASoC: qcom: sm8250: explicitly set format in sm8250_be_hw_params_fixup() [ Upstream commit 89be3c15a58b2ccf31e969223c8ac93ca8932d81 ] Setting format to s16le is required for compressed playback on compatible soundcards. Cc: Srinivas Kandagatla Signed-off-by: Alexey Klimov Link: https://patch.msgid.link/20250228161430.373961-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 84c069dc5fc8970a2554816dea36c10d897d0587 Author: Andy Shevchenko Date: Mon Feb 24 19:27:38 2025 +0200 auxdisplay: charlcd: Partially revert "Move hwidth and bwidth to struct hd44780_common" [ Upstream commit 09965a142078080fe7807bab0f6f1890cb5987a4 ] Commit 2545c1c948a6 ("auxdisplay: Move hwidth and bwidth to struct hd44780_common") makes charlcd_alloc() argument-less effectively dropping the single allocation for the struct charlcd_priv object along with the driver specific one. Restore that behaviour here. Signed-off-by: Andy Shevchenko Reviewed-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 53ce7542861806023b96c7fe03ae1229556a48a7 Author: Andreas Gruenbacher Date: Thu Feb 6 14:58:39 2025 +0100 gfs2: Check for empty queue in run_queue [ Upstream commit d838605fea6eabae3746a276fd448f6719eb3926 ] In run_queue(), check if the queue of pending requests is empty instead of blindly assuming that it won't be. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ff11cd673e477d3311db3476659d08b9ad361ef6 Author: Leon Huang Date: Tue Feb 11 15:45:43 2025 +0800 drm/amd/display: Fix incorrect DPCD configs while Replay/PSR switch [ Upstream commit 0d9cabc8f591ea1cd97c071b853b75b155c13259 ] [Why] When switching between PSR/Replay, the DPCD config of previous mode is not cleared, resulting in unexpected behavior in TCON. [How] Initialize the DPCD in setup function Reviewed-by: Robin Chen Signed-off-by: Leon Huang Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ed7eda66b20cbb0ffb3c8db63406f2732b7ef2de Author: Peichen Huang Date: Tue Feb 25 14:52:30 2025 +0800 drm/amd/display: not abort link train when bw is low [ Upstream commit 8a21da2842bb22b2b80e5902d0438030d729bfd3 ] [WHY] DP tunneling should not abort link train even bandwidth become too low after downgrade. Otherwise, it would fail compliance test. [HOW} Do link train with downgrade settings even bandwidth is not enough Reviewed-by: Cruise Hung Reviewed-by: Meenakshikumar Somasundaram Signed-off-by: Peichen Huang Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 83e4f1de0802b7f82dc59325b905b759627a8f39 Author: Zhikai Zhai Date: Thu Feb 27 20:09:14 2025 +0800 drm/amd/display: calculate the remain segments for all pipes [ Upstream commit d3069feecdb5542604d29b59acfd1fd213bad95b ] [WHY] In some cases the remain de-tile buffer segments will be greater than zero if we don't add the non-top pipe to calculate, at this time the override de-tile buffer size will be valid and used. But it makes the de-tile buffer segments used finally for all of pipes exceed the maximum. [HOW] Add the non-top pipe to calculate the remain de-tile buffer segments. Don't set override size to use the average according to pipe count if the value exceed the maximum. Reviewed-by: Charlene Liu Signed-off-by: Zhikai Zhai Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 65e51bc2803bb9c19df74c7014c45fb5b1b96582 Author: Charlene Liu Date: Mon Mar 3 13:53:16 2025 -0500 drm/amd/display: remove minimum Dispclk and apply oem panel timing. [ Upstream commit 756e58e83e89d372b94269c0cde61fe55da76947 ] [why & how] 1. apply oem panel timing (not only on OLED) 2. remove MIN_DPP_DISP_CLK request in driver. This fix will apply for dcn31x but not sync with DML's output. Reviewed-by: Ovidiu Bunea Signed-off-by: Charlene Liu Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c1502fc84d1c65e17ba25fcde1c52cbe52f79157 Author: Willem de Bruijn Date: Thu Mar 6 22:34:09 2025 -0500 ipv6: save dontfrag in cork [ Upstream commit a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a ] When spanning datagram construction over multiple send calls using MSG_MORE, per datagram settings are configured on the first send. That is when ip(6)_setup_cork stores these settings for subsequent use in __ip(6)_append_data and others. The only flag that escaped this was dontfrag. As a result, a datagram could be constructed with df=0 on the first sendmsg, but df=1 on a next. Which is what cmsg_ip.sh does in an upcoming MSG_MORE test in the "diff" scenario. Changing datagram conditions in the middle of constructing an skb makes this already complex code path even more convoluted. It is here unintentional. Bring this flag in line with expected sockopt/cmsg behavior. And stop passing ipc6 to __ip6_append_data, to avoid such issues in the future. This is already the case for __ip_append_data. inet6_cork had a 6 byte hole, so the 1B flag has no impact. Signed-off-by: Willem de Bruijn Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20250307033620.411611-3-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit faba68a86ab7993436b510dbee8a022371ffd9b3 Author: Anjaneyulu Date: Sat Mar 8 23:03:30 2025 +0200 wifi: cfg80211: allow IR in 20 MHz configurations [ Upstream commit cf4bd1608882792d4742e27a819493312904a680 ] Some regulatory bodies doesn't allow IR (initiate radioation) on a specific subband, but allows it for channels with a bandwidth of 20 MHz. Add a channel flag that indicates that, and consider it in cfg80211_reg_check_beaconing. While on it, fix the kernel doc of enum nl80211_reg_rule_flags and change it to use BIT(). Signed-off-by: Anjaneyulu Co-developed-by: Somashekhar Puttagangaiah Signed-off-by: Somashekhar Puttagangaiah Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308225541.d3ab352a73ff.I8a8f79e1c9eb74936929463960ee2a324712fe51@changeid [fix typo] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 22d8cc7f5d5a9ad9be8897e4783b129c12bc570c Author: Ilan Peer Date: Sat Mar 8 23:03:34 2025 +0200 wifi: mac80211_hwsim: Fix MLD address translation [ Upstream commit 65bff0be9b154621b617fc2e4bd89f1e18e97cdb ] Do address translations only between shared links. It is possible that while an non-AP MLD station and an AP MLD station have shared links, the frame is intended to be sent on a link which is not shared (for example when sending a probe response). Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308225541.1aa461270bb6.Ic21592e1b1634653f02b80628cb2152f6e9de367@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 07709d31829fd22ceb93b0cf7f2042e6d7e58230 Author: Johannes Berg Date: Sat Mar 8 23:03:36 2025 +0200 wifi: mac80211: fix warning on disconnect during failed ML reconf [ Upstream commit 0e104aa3676d020f6c442cd7fbaeb72adaaab6fc ] If multi-link reconfiguration fails, we can disconnect with a local link already allocated but the BSS entry not assigned yet, which leads to a warning in cfg80211. Add a check to avoid the warning. Signed-off-by: Johannes Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308225541.699bd9cbabe5.I599d5ff69092a65e916e2acd25137ae9df8debe8@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a791a6bf02c493a82d051ba59067e84505d4fc23 Author: Emmanuel Grumbach Date: Sat Mar 8 23:19:13 2025 +0200 wifi: iwlwifi: fix the ECKV UEFI variable name [ Upstream commit 3ea2970b0578011ab8402ad0cff39712255f63df ] This UEFI variable name was badly named. Fix its name and also use the right GUID to find it: we need to use the BT_WIFI (a.k.a. Common) GUID. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308231426.78c998d0fa71.I2bc9d72c1dc2c4d7028f0265634a940c2fadbbb5@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7ce37a3ca0907e031bbbd8754c6cf7779390c168 Author: Johannes Berg Date: Sat Mar 8 23:19:17 2025 +0200 wifi: iwlwifi: mark Br device not integrated [ Upstream commit 5f0ab2f35a43773a0dfe1297129a8dbff906b932 ] This is a discrete device, don't mark it as integrated. This also means we cannot set the LTR delay. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308231427.9bb69393fcc9.I197129383e5441c8139cbb0e810ae0b71198a37c@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 181e8b56b74ad3920456dcdc8a361520d9007956 Author: Johannes Berg Date: Sat Mar 8 23:19:18 2025 +0200 wifi: iwlwifi: fix debug actions order [ Upstream commit eb29b4ffafb20281624dcd2cbb768d6f30edf600 ] The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308231427.6de7fa8e63ed.I40632c48e2a67a8aca05def572a934b88ce7934b@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1c55feb63827f7d1b79369fa7ff37187c74648a2 Author: Daniel Gabay Date: Sat Mar 8 23:19:19 2025 +0200 wifi: iwlwifi: w/a FW SMPS mode selection [ Upstream commit b2e709805ce955f80803b7cab3421813c79e1df4 ] The FW is now responsible of determining the SMPS mode. If the user disabled power save in a certain vif, we send the vif-level power command to clear out the POWER_FLAGS_POWER_MANAGEMENT_ENA_MSK bit for that vif. But erroneously, the FW checks DEVICE_POWER_FLAGS_POWER_SAVE_ENA_MSK in the device-level command to determine the SMPS mode. To W/A this, send also the device-level command when the power save of a vif changes, and disable power save if there is any vif that has power save disabled. Signed-off-by: Daniel Gabay Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308231427.7bf205efa027.I2c793ff1fc2a6779a95faaee1ded348100fd97f1@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0446d34a853d9576e2a7628c803d2abd2f8cf3a8 Author: Miri Korenblit Date: Sat Mar 8 23:19:23 2025 +0200 wifi: iwlwifi: don't warn when if there is a FW error [ Upstream commit c7f50d0433a016d43681592836a3d484817bfb34 ] iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently. Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308231427.ba3d90b22c25.I9332506af1997faefcf0bdb51d98d5e874051722@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 101a3b9920a79832dc55efc4296ca246bde5e566 Author: Marcos Paulo de Souza Date: Wed Feb 26 16:59:05 2025 -0300 printk: Check CON_SUSPEND when unblanking a console [ Upstream commit 72c96a2dacc0fb056d13a5f02b0845c4c910fe54 ] The commit 9e70a5e109a4 ("printk: Add per-console suspended state") introduced the CON_SUSPENDED flag for consoles. The suspended consoles will stop receiving messages, so don't unblank suspended consoles because it won't be showing anything either way. Signed-off-by: Marcos Paulo de Souza Reviewed-by: Petr Mladek Reviewed-by: John Ogness Link: https://lore.kernel.org/r/20250226-printk-renaming-v1-5-0b878577f2e6@suse.com Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 063ad8885c7c61ff23ddf5a52c3b5c04968c6a56 Author: Robin Murphy Date: Fri Feb 28 15:46:32 2025 +0000 iommu: Keep dev->iommu state consistent [ Upstream commit 3832862eb9c4dfa0e80b2522bfaedbc8a43de97d ] At the moment, if of_iommu_configure() allocates dev->iommu itself via iommu_fwspec_init(), then suffers a DT parsing failure, it cleans up the fwspec but leaves the empty dev_iommu hanging around. So far this is benign (if a tiny bit wasteful), but we'd like to be able to reason about dev->iommu having a consistent and unambiguous lifecycle. Thus make sure that the of_iommu cleanup undoes precisely whatever it did. Signed-off-by: Robin Murphy Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/d219663a3f23001f23d520a883ac622d70b4e642.1740753261.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a21f1607d0b3c7328333c9b3bfda4087d88a6e13 Author: Kurt Borja Date: Tue Mar 4 00:52:50 2025 -0500 hwmon: (dell-smm) Increment the number of fans [ Upstream commit dbcfcb239b3b452ef8782842c36fb17dd1b9092f ] Some Alienware laptops that support the SMM interface, may have up to 4 fans. Tested on an Alienware x15 r1. Signed-off-by: Kurt Borja Link: https://lore.kernel.org/r/20250304055249.51940-2-kuurtb@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit aef1b639ae2a8a966118c45bda1559419cea7ac6 Author: Avraham Stern Date: Sat Mar 8 23:19:25 2025 +0200 wifi: iwlwifi: mvm: fix setting the TK when associated [ Upstream commit 3ad61970ac9e164be1b09b46c01aa942e8966132 ] When running secured ranging and the initiator is associated with the responder, the TK was not set in the range request command. Fix it. Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250308231427.603dc31579d9.Icd19d797e56483c08dd22c55b96fee481c4d2f3d@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3a75fe58a164a22eada1c4ac8a1cbf53ca26625e Author: Michal Pecio Date: Tue Mar 11 17:45:50 2025 +0200 usb: xhci: Don't change the status of stalled TDs on failed Stop EP [ Upstream commit dfc88357b6b6356dadea06b2c0bc8041f5e11720 ] When the device stalls an endpoint, current TD is assigned -EPIPE status and Reset Endpoint is queued. If a Stop Endpoint is pending at the time, it will run before Reset Endpoint and fail due to the stall. Its handler will change TD's status to -EPROTO before Reset Endpoint handler runs and initiates giveback. Check if the stall has already been handled and don't try to do it again. Since xhci_handle_halted_endpoint() performs this check too, not overwriting td->status is the only difference. I haven't seen this case yet, but I have seen a related one where the xHC has already executed Reset Endpoint, EP Context state is now Stopped and EP_HALTED is set. If the xHC took a bit longer to execute Reset Endpoint, said case would become this one. Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250311154551.4035726-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 28306c58daf81bdfb01b1f12fa5936a1d5afbefa Author: Erick Shepherd Date: Tue Feb 11 15:46:45 2025 -0600 mmc: sdhci: Disable SD card clock before changing parameters [ Upstream commit fb3bbc46c94f261b6156ee863c1b06c84cf157dc ] Per the SD Host Controller Simplified Specification v4.20 §3.2.3, change the SD card clock parameters only after first disabling the external card clock. Doing this fixes a spurious clock pulse on Baytrail and Apollo Lake SD controllers which otherwise breaks voltage switching with a specific Swissbit SD card. Signed-off-by: Kyle Roeschley Signed-off-by: Brad Mouring Signed-off-by: Erick Shepherd Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20250211214645.469279-1-erick.shepherd@ni.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 38828e0dc771c730c9289d4a6deb8815ad3867ed Author: Kaustabh Chakraborty Date: Wed Feb 19 00:17:49 2025 +0530 mmc: dw_mmc: add exynos7870 DW MMC support [ Upstream commit 7cbe799ac10fd8be85af5e0615c4337f81e575f3 ] Add support for Exynos7870 DW MMC controllers, for both SMU and non-SMU variants. These controllers require a quirk to access 64-bit FIFO in 32-bit accesses (DW_MMC_QUIRK_FIFO64_32). Signed-off-by: Kaustabh Chakraborty Link: https://lore.kernel.org/r/20250219-exynos7870-mmc-v2-3-b4255a3e39ed@disroot.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8ad58a7eba6db85301d873d91a51b49fdb6505ef Author: Ryan Roberts Date: Fri Feb 21 10:12:25 2025 +0530 arm64/mm: Check PUD_TYPE_TABLE in pud_bad() [ Upstream commit bfb1d2b9021c21891427acc86eb848ccedeb274e ] pud_bad() is currently defined in terms of pud_table(). Although for some configs, pud_table() is hard-coded to true i.e. when using 64K base pages or when page table levels are less than 3. pud_bad() is intended to check that the pud is configured correctly. Hence let's open-code the same check that the full version of pud_table() uses into pud_bad(). Then it always performs the check regardless of the config. Cc: Will Deacon Cc: Ard Biesheuvel Cc: Ryan Roberts Cc: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ryan Roberts Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250221044227.1145393-7-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 6215143ad372d1e5f0bb5e2e934a426758653d09 Author: Ryan Roberts Date: Fri Feb 21 10:12:26 2025 +0530 arm64/mm: Check pmd_table() in pmd_trans_huge() [ Upstream commit d1770e909898c108e8c7d30ca039053e8818a9c9 ] Check for pmd_table() in pmd_trans_huge() rather then just checking for the PMD_TABLE_BIT. But ensure all present-invalid entries are handled correctly by always setting PTE_VALID before checking with pmd_table(). Cc: Will Deacon Cc: Ard Biesheuvel Cc: Ryan Roberts Cc: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ryan Roberts Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250221044227.1145393-8-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 4f89f257f32da7f5cd5312bc44b47b2be56ee597 Author: Andy Yan Date: Wed Mar 12 16:00:07 2025 +0800 phy: rockchip: usbdp: Only verify link rates/lanes/voltage when the corresponding set flags are set [ Upstream commit 969a38be437b68dc9e12e3c3f08911c9f9c8be73 ] According documentation of phy_configure_opts_dp, at the configure stage, link rates should only be verify/configure when set_rate flag is set, the same applies to lanes and voltage. So do it as the documentation says. Because voltage setting depends on the lanes, link rates set previously, so record the link rates and lanes at it's verify stage. Signed-off-by: Andy Yan Link: https://lore.kernel.org/r/20250312080041.524546-1-andyshrk@163.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 236a87e9d21105438a05fdf39e75526341e4bc42 Author: Kees Cook Date: Mon Mar 10 15:24:33 2025 -0700 PNP: Expand length of fixup id string [ Upstream commit 425b1c97b07f2290700f708edabef32861e2b2db ] GCC 15's -Wunterminated-string-initialization saw that "id" was not including the required trailing NUL character. Instead of marking "id" with __nonstring[1], expand the length of the string as it is used in (debugging) format strings that expect a properly formed C string. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Signed-off-by: Kees Cook Link: https://patch.msgid.link/20250310222432.work.826-kees@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 21153e0974fccb6aa9fa8db6dd5e902c4c664747 Author: Nicolas Bouchinet Date: Wed Jan 29 18:06:30 2025 +0100 netfilter: conntrack: Bound nf_conntrack sysctl writes [ Upstream commit 8b6861390ffee6b8ed78b9395e3776c16fec6579 ] nf_conntrack_max and nf_conntrack_expect_max sysctls were authorized to be written any negative value, which would then be stored in the unsigned int variables nf_conntrack_max and nf_ct_expect_max variables. While the do_proc_dointvec_conv function is supposed to limit writing handled by proc_dointvec proc_handler to INT_MAX. Such a negative value being written in an unsigned int leads to a very high value, exceeding this limit. Moreover, the nf_conntrack_expect_max sysctl documentation specifies the minimum value is 1. The proc_handlers have thus been updated to proc_dointvec_minmax in order to specify the following write bounds : * Bound nf_conntrack_max sysctl writings between SYSCTL_ZERO and SYSCTL_INT_MAX. * Bound nf_conntrack_expect_max sysctl writings between SYSCTL_ONE and SYSCTL_INT_MAX as defined in the sysctl documentation. With this patch applied, sysctl writes outside the defined in the bound will thus lead to a write error : ``` sysctl -w net.netfilter.nf_conntrack_expect_max=-1 sysctl: setting key "net.netfilter.nf_conntrack_expect_max": Invalid argument ``` Signed-off-by: Nicolas Bouchinet Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 42101748275867dbcf8a527891687ab5a4c1e28a Author: Dian-Syuan Yang Date: Thu Mar 6 10:11:44 2025 +0800 wifi: rtw89: set force HE TB mode when connecting to 11ax AP [ Upstream commit a9b56f219a0fa550f92e65ac58443a7892380e09 ] Some of 11ax AP set the UL HE-SIG-A2 reserved subfield to all 0s, which will cause the 11be chip to recognize trigger frame as EHT. We propose a method to bypass the "UL HE-SIG-A2 reserved subfield" and always uses HE TB in response to the AP's trigger frame. Signed-off-by: Dian-Syuan Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250306021144.12854-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit 3fb9ee05ec15ff3d60a1217f65228221fbace3c2 Author: Thomas Weißschuh Date: Tue Mar 11 10:54:47 2025 +0100 timer_list: Don't use %pK through printk() [ Upstream commit a52067c24ccf6ee4c85acffa0f155e9714f9adce ] This reverts commit f590308536db ("timer debug: Hide kernel addresses via %pK in /proc/timer_list") The timer list helper SEQ_printf() uses either the real seq_printf() for procfs output or vprintk() to print to the kernel log, when invoked from SysRq-q. It uses %pK for printing pointers. In the past %pK was prefered over %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer, easier to reason about and sufficient here. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Link: https://lore.kernel.org/all/20250311-restricted-pointers-timer-v1-1-6626b91e54ab@linutronix.de Signed-off-by: Sasha Levin commit 6e816a97fa840b129d277a56af3b36196f5ffafb Author: Jaakko Karrenpalo Date: Fri Mar 7 18:16:59 2025 +0200 net: hsr: Fix PRP duplicate detection [ Upstream commit 05fd00e5e7b1ac60d264f72423fba38cc382b447 ] Add PRP specific function for handling duplicate packets. This is needed because of potential L2 802.1p prioritization done by network switches. The L2 prioritization can re-order the PRP packets from a node causing the existing implementation to discard the frame(s) that have been received 'late' because the sequence number is before the previous received packet. This can happen if the node is sending multiple frames back-to-back with different priority. Signed-off-by: Jaakko Karrenpalo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250307161700.1045-1-jkarrenpalo@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f933879c5b6a64ca0f5b4a68f0ea8b76c295d6d5 Author: Jonas Karlman Date: Sat Mar 8 21:37:14 2025 +0000 net: stmmac: dwmac-rk: Validate GRF and peripheral GRF during probe [ Upstream commit 247e84f66a3d1946193d739fec5dc3d69833fd00 ] All Rockchip GMAC variants typically write to GRF regs to control e.g. interface mode, speed and MAC rx/tx delay. Newer SoCs such as RK3576 and RK3588 use a mix of GRF and peripheral GRF regs. These syscon regmaps is located with help of a rockchip,grf and rockchip,php-grf phandle. However, validating the rockchip,grf and rockchip,php-grf syscon regmap is deferred until e.g. interface mode or speed is configured, inside the individual SoC specific operations. Change to validate the rockchip,grf and rockchip,php-grf syscon regmap at probe time to simplify all SoC specific operations. This should not introduce any backward compatibility issues as all GMAC nodes have been added together with a rockchip,grf phandle (and rockchip,php-grf where required) in their initial commit. Signed-off-by: Jonas Karlman Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250308213720.2517944-3-jonas@kwiboo.se Reviewed-by: Sebastian Reichel Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ae22452d15c89d3cec3d7e0e5a7041f41c2efb2e Author: Thomas Gleixner Date: Sat Mar 8 17:48:10 2025 +0100 posix-timers: Ensure that timer initialization is fully visible [ Upstream commit 2389c6efd3ad8edb3bcce0019b4edcc7d9c7de19 ] Frederic pointed out that the memory operations to initialize the timer are not guaranteed to be visible, when __lock_timer() observes timer::it_signal valid under timer::it_lock: T0 T1 --------- ----------- do_timer_create() // A new_timer->.... = .... spin_lock(current->sighand) // B WRITE_ONCE(new_timer->it_signal, current->signal) spin_unlock(current->sighand) sys_timer_*() t = __lock_timer() spin_lock(&timr->it_lock) // observes B if (timr->it_signal == current->signal) return timr; if (!t) return; // Is not guaranteed to observe A Protect the write of timer::it_signal, which makes the timer valid, with timer::it_lock as well. This guarantees that T1 must observe the initialization A completely, when it observes the valid signal pointer under timer::it_lock. sighand::siglock must still be taken to protect the signal::posix_timers list. Reported-by: Frederic Weisbecker Suggested-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/all/20250308155623.507944489@linutronix.de Signed-off-by: Sasha Levin commit d0dc233fe22412b2ddec3ead6419a495f2769d1f Author: Eric Dumazet Date: Sat Mar 8 17:48:17 2025 +0100 posix-timers: Add cond_resched() to posix_timer_add() search loop [ Upstream commit 5f2909c6cd13564a07ae692a95457f52295c4f22 ] With a large number of POSIX timers the search for a valid ID might cause a soft lockup on PREEMPT_NONE/VOLUNTARY kernels. Add cond_resched() to the loop to prevent that. [ tglx: Split out from Eric's series ] Signed-off-by: Eric Dumazet Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/all/20250214135911.2037402-2-edumazet@google.com Link: https://lore.kernel.org/all/20250308155623.635612865@linutronix.de Signed-off-by: Sasha Levin commit 135dde13b96d565d8bcd69e7350f29fc1aade0e5 Author: Maher Sanalla Date: Wed Feb 26 15:54:13 2025 +0200 RDMA/uverbs: Propagate errors from rdma_lookup_get_uobject() [ Upstream commit 81f8f7454ad9e0bf95efdec6542afdc9a6ab1e24 ] Currently, the IB uverbs API calls uobj_get_uobj_read(), which in turn uses the rdma_lookup_get_uobject() helper to retrieve user objects. In case of failure, uobj_get_uobj_read() returns NULL, overriding the error code from rdma_lookup_get_uobject(). The IB uverbs API then translates this NULL to -EINVAL, masking the actual error and complicating debugging. For example, applications calling ibv_modify_qp that fails with EBUSY when retrieving the QP uobject will see the overridden error code EINVAL instead, masking the actual error. Furthermore, based on rdma-core commit: "2a22f1ced5f3 ("Merge pull request #1568 from jakemoroni/master")" Kernel's IB uverbs return values are either ignored and passed on as is to application or overridden with other errnos in a few cases. Thus, to improve error reporting and debuggability, propagate the original error from rdma_lookup_get_uobject() instead of replacing it with EINVAL. Signed-off-by: Maher Sanalla Link: https://patch.msgid.link/64f9d3711b183984e939962c2f83383904f97dfb.1740577869.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 785ac699113320e3c3968754ca0c78d40a013107 Author: Baokun Li Date: Wed Jan 22 19:05:26 2025 +0800 ext4: do not convert the unwritten extents if data writeback fails [ Upstream commit e856f93e0fb249955f7d5efb18fe20500a9ccc6d ] When dioread_nolock is turned on (the default), it will convert unwritten extents to written at ext4_end_io_end(), even if the data writeback fails. It leads to the possibility that stale data may be exposed when the physical block corresponding to the file data is read-only (i.e., writes return -EIO, but reads are normal). Therefore a new ext4_io_end->flags EXT4_IO_END_FAILED is added, which indicates that some bio write-back failed in the current ext4_io_end. When this flag is set, the unwritten to written conversion is no longer performed. Users can read the data normally until the caches are dropped, after that, the failed extents can only be read to all 0. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250122110533.4116662-3-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 2f5f326214321c1f2ab07f820736900381e0c018 Author: Baokun Li Date: Wed Jan 22 19:05:27 2025 +0800 ext4: reject the 'data_err=abort' option in nojournal mode [ Upstream commit 26343ca0df715097065b02a6cddb4a029d5b9327 ] data_err=abort aborts the journal on I/O errors. However, this option is meaningless if journal is disabled, so it is rejected in nojournal mode to reduce unnecessary checks. Also, this option is ignored upon remount. Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250122110533.4116662-4-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3039f0c9c75548dc54e9968e123b990090310708 Author: Taniya Das Date: Fri Feb 21 15:04:55 2025 +0530 clk: qcom: lpassaudiocc-sc7280: Add support for LPASS resets for QCM6490 [ Upstream commit cdbbc480f4146cb659af97f4020601fde5fb65a7 ] On the QCM6490 boards, the LPASS firmware controls the complete clock controller functionalities and associated power domains. However, only the LPASS resets required to be controlled by the high level OS. Thus, add support for the resets in the clock driver to enable the Audio SW driver to assert/deassert the audio resets as needed. Reviewed-by: Dmitry Baryshkov Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20250221-lpass_qcm6490_resets-v5-2-6be0c0949a83@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3673382803c51cda73fab1df1057ea73d366da23 Author: Ryan Walklin Date: Sat Feb 15 11:02:25 2025 +1300 ASoC: sun4i-codec: support hp-det-gpios property [ Upstream commit a149377c033afe6557c50892ebbfc0e8b7e2e253 ] Add support for GPIO headphone detection with the hp-det-gpios property. In order for this to properly disable the path upon removal of headphones, the output must be labelled Headphone which is a common sink in the driver. Describe a headphone jack and detection GPIO in the driver, check for a corresponding device tree node, and enable jack detection in a new machine init function if described. Signed-off-by: Chris Morgan Signed-off-by: Ryan Walklin -- Changelog v1..v2: - Separate DAPM changes into separate patch and add rationale. Tested-by: Philippe Simons Link: https://patch.msgid.link/20250214220247.10810-4-ryan@testtoast.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de3c09de746f7d68b63efad491aa952e442f72ab Author: David Rosca Date: Fri Feb 28 13:44:32 2025 +0100 drm/amdgpu: Update SRIOV video codec caps [ Upstream commit 19478f2011f8b53dee401c91423c4e0b73753e4f ] There have been multiple fixes to the video caps that are missing for SRIOV. Update the SRIOV caps with correct values. Signed-off-by: David Rosca Acked-by: Alex Deucher Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 858425dc2df3ea3edf8ab719723b8fffc20b5634 Author: Alex Deucher Date: Wed Feb 26 15:55:33 2025 -0500 drm/amdgpu/gfx11: don't read registers in mqd init [ Upstream commit e27b36ea6ba5f29e91fcfb375ea29503708fcf43 ] Just use the default values. There's not need to get the value from hardware and it could cause problems if we do that at runtime and gfxoff is active. Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 73d437ae63ce600a188431d2b9bd3aa157f45cb3 Author: Alex Deucher Date: Wed Feb 26 16:08:03 2025 -0500 drm/amdgpu/gfx12: don't read registers in mqd init [ Upstream commit fc3c139cf0432b79fd08e23100a559ee51cd0be4 ] Just use the default values. There's not need to get the value from hardware and it could cause problems if we do that at runtime and gfxoff is active. Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 580750a317d7b09eab13c035478193fca0ea50cb Author: Shree Ramamoorthy Date: Thu Feb 6 11:37:23 2025 -0600 mfd: tps65219: Remove TPS65219_REG_TI_DEV_ID check [ Upstream commit 76b58d5111fdcffce615beb71520bc7a6f1742c9 ] The chipid macro/variable and regmap_read function call is not needed because the TPS65219_REG_TI_DEV_ID register value is not a consistent value across TPS65219 PMIC config versions. Reading from the DEV_ID register without a consistent value to compare it to isn't useful. There isn't a way to verify the match data ID is the same ID read from the DEV_ID device register. 0xF0 isn't a DEV_ID value consistent across TPS65219 NVM configurations. For TPS65215, there is a consistent value in bits 5-0 of the DEV_ID register. However, there are other error checks in place within probe() that apply to both PMICs rather than keeping this isolated check for one PMIC. Signed-off-by: Shree Ramamoorthy Link: https://lore.kernel.org/r/20250206173725.386720-4-s-ramamoorthy@ti.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 27b19f29c9a06da43fd6f1c54c359edc715fc01c Author: Prathamesh Shete Date: Wed Mar 5 16:19:39 2025 +0530 pinctrl-tegra: Restore SFSEL bit when freeing pins [ Upstream commit c12bfa0fee65940b10ff5187349f76c6f6b1df9c ] Each pin can be configured as a Special Function IO (SFIO) or GPIO, where the SFIO enables the pin to operate in alternative modes such as I2C, SPI, etc. The current implementation sets all the pins back to SFIO mode even if they were initially in GPIO mode. This can cause glitches on the pins when pinctrl_gpio_free() is called. Avoid these undesired glitches by storing the pin's SFIO/GPIO state on GPIO request and restoring it on GPIO free. Signed-off-by: Prathamesh Shete Link: https://lore.kernel.org/20250305104939.15168-2-pshete@nvidia.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f5363ffdabc2a281bd0023584944e3d0c25dfcd3 Author: Frediano Ziglio Date: Thu Feb 27 14:50:15 2025 +0000 xen: Add support for XenServer 6.1 platform device [ Upstream commit 2356f15caefc0cc63d9cc5122641754f76ef9b25 ] On XenServer on Windows machine a platform device with ID 2 instead of 1 is used. This device is mainly identical to device 1 but due to some Windows update behaviour it was decided to use a device with a different ID. This causes compatibility issues with Linux which expects, if Xen is detected, to find a Xen platform device (5853:0001) otherwise code will crash due to some missing initialization (specifically grant tables). Specifically from dmesg RIP: 0010:gnttab_expand+0x29/0x210 Code: 90 0f 1f 44 00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 89 fd 41 54 53 48 83 ec 10 48 8b 05 7e 9a 49 02 44 8b 35 a7 9a 49 02 <8b> 48 04 8d 44 39 ff f7 f1 45 8d 24 06 89 c3 e8 43 fe ff ff 44 39 RSP: 0000:ffffba34c01fbc88 EFLAGS: 00010086 ... The device 2 is presented by Xapi adding device specification to Qemu command line. Signed-off-by: Frediano Ziglio Acked-by: Juergen Gross Message-ID: <20250227145016.25350-1-frediano.ziglio@cloud.com> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 8ef935698f3fd422db0c010ce392d035125211f9 Author: Guangguan Wang Date: Tue Mar 4 20:43:04 2025 +0800 net/smc: use the correct ndev to find pnetid by pnetid table [ Upstream commit bfc6c67ec2d64d0ca4e5cc3e1ac84298a10b8d62 ] When using smc_pnet in SMC, it will only search the pnetid in the base_ndev of the netdev hierarchy(both HW PNETID and User-defined sw pnetid). This may not work for some scenarios when using SMC in container on cloud environment. In container, there have choices of different container network, such as directly using host network, virtual network IPVLAN, veth, etc. Different choices of container network have different netdev hierarchy. Examples of netdev hierarchy show below. (eth0 and eth1 in host below is the netdev directly related to the physical device). _______________________________ | _________________ | | |POD | | | | | | | | eth0_________ | | | |____| |__| | | | | | | | | | | eth1|base_ndev| eth0_______ | | | | | RDMA || | host |_________| |_______|| --------------------------------- netdev hierarchy if directly using host network ________________________________ | _________________ | | |POD __________ | | | | |upper_ndev| | | | |eth0|__________| | | | |_______|_________| | | |lower netdev | | __|______ | | eth1| | eth0_______ | | |base_ndev| | RDMA || | host |_________| |_______|| --------------------------------- netdev hierarchy if using IPVLAN _______________________________ | _____________________ | | |POD _________ | | | | |base_ndev|| | | |eth0(veth)|_________|| | | |____________|________| | | |pairs | | _______|_ | | | | eth0_______ | | veth|base_ndev| | RDMA || | |_________| |_______|| | _________ | | eth1|base_ndev| | | host |_________| | --------------------------------- netdev hierarchy if using veth Due to some reasons, the eth1 in host is not RDMA attached netdevice, pnetid is needed to map the eth1(in host) with RDMA device so that POD can do SMC-R. Because the eth1(in host) is managed by CNI plugin(such as Terway, network management plugin in container environment), and in cloud environment the eth(in host) can dynamically be inserted by CNI when POD create and dynamically be removed by CNI when POD destroy and no POD related to the eth(in host) anymore. It is hard to config the pnetid to the eth1(in host). But it is easy to config the pnetid to the netdevice which can be seen in POD. When do SMC-R, both the container directly using host network and the container using veth network can successfully match the RDMA device, because the configured pnetid netdev is a base_ndev. But the container using IPVLAN can not successfully match the RDMA device and 0x03030000 fallback happens, because the configured pnetid netdev is not a base_ndev. Additionally, if config pnetid to the eth1(in host) also can not work for matching RDMA device when using veth network and doing SMC-R in POD. To resolve the problems list above, this patch extends to search user -defined sw pnetid in the clc handshake ndev when no pnetid can be found in the base_ndev, and the base_ndev take precedence over ndev for backward compatibility. This patch also can unify the pnetid setup of different network choices list above in container(Config user-defined sw pnetid in the netdevice can be seen in POD). Signed-off-by: Guangguan Wang Reviewed-by: Wenjia Zhang Reviewed-by: Halil Pasic Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 174dedce648aaad39e4a9d514a7d73dc06786b64 Author: Mikulas Patocka Date: Fri Mar 14 13:51:32 2025 +0100 dm: restrict dm device size to 2^63-512 bytes [ Upstream commit 45fc728515c14f53f6205789de5bfd72a95af3b8 ] The devices with size >= 2^63 bytes can't be used reliably by userspace because the type off_t is a signed 64-bit integer. Therefore, we limit the maximum size of a device mapper device to 2^63-512 bytes. Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit ee87fc3a1271fa50a1b6cb5523bc10f4f5d9ad38 Author: Shashank Gupta Date: Wed Mar 5 13:27:05 2025 +0530 crypto: octeontx2 - suppress auth failure screaming due to negative tests [ Upstream commit 64b7871522a4cba99d092e1c849d6f9092868aaa ] This patch addresses an issue where authentication failures were being erroneously reported due to negative test failures in the "ccm(aes)" selftest. pr_debug suppress unnecessary screaming of these tests. Signed-off-by: Shashank Gupta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 572ed3fb99c4ea267fe7afdd96fab2263e49cc7f Author: Masahiro Yamada Date: Sat Feb 8 03:41:55 2025 +0900 kconfig: do not clear SYMBOL_VALID when reading include/config/auto.conf [ Upstream commit 226ac19c217f24f0927d0a73cf9ee613971a188d ] When conf_read_simple() is called with S_DEF_AUTO, it is meant to read previous symbol values from include/config/auto.conf to determine which include/config/* files should be touched. This process should not modify the current symbol status in any way. However, conf_touch_deps() currently invalidates all symbol values and recalculates them, which is totally unneeded. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 61d7c8a75344588af1b7d2cb22150d2b1261e07a Author: Seyediman Seyedarab Date: Sat Mar 1 17:21:37 2025 -0500 kbuild: fix argument parsing in scripts/config [ Upstream commit f757f6011c92b5a01db742c39149bed9e526478f ] The script previously assumed --file was always the first argument, which caused issues when it appeared later. This patch updates the parsing logic to scan all arguments to find --file, sets the config file correctly, and resets the argument list with the remaining commands. It also fixes --refresh to respect --file by passing KCONFIG_CONFIG=$FN to make oldconfig. Signed-off-by: Seyediman Seyedarab Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 555c0b713ca83968d3c843cb15485b9ba3367b1b Author: Yonghong Song Date: Mon Feb 24 15:01:16 2025 -0800 bpf: Allow pre-ordering for bpf cgroup progs [ Upstream commit 4b82b181a26cff8bf7adc3a85a88d121d92edeaf ] Currently for bpf progs in a cgroup hierarchy, the effective prog array is computed from bottom cgroup to upper cgroups (post-ordering). For example, the following cgroup hierarchy root cgroup: p1, p2 subcgroup: p3, p4 have BPF_F_ALLOW_MULTI for both cgroup levels. The effective cgroup array ordering looks like p3 p4 p1 p2 and at run time, progs will execute based on that order. But in some cases, it is desirable to have root prog executes earlier than children progs (pre-ordering). For example, - prog p1 intends to collect original pkt dest addresses. - prog p3 will modify original pkt dest addresses to a proxy address for security reason. The end result is that prog p1 gets proxy address which is not what it wants. Putting p1 to every child cgroup is not desirable either as it will duplicate itself in many child cgroups. And this is exactly a use case we are encountering in Meta. To fix this issue, let us introduce a flag BPF_F_PREORDER. If the flag is specified at attachment time, the prog has higher priority and the ordering with that flag will be from top to bottom (pre-ordering). For example, in the above example, root cgroup: p1, p2 subcgroup: p3, p4 Let us say p2 and p4 are marked with BPF_F_PREORDER. The final effective array ordering will be p2 p4 p3 p1 Suggested-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20250224230116.283071-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6c303960b14434bb029fb511a1e0fdf8758819d8 Author: Nícolas F. R. A. Prado Date: Thu Mar 6 16:52:17 2025 -0300 ASoC: mediatek: mt6359: Add stub for mt6359_accdet_enable_jack_detect [ Upstream commit 0116a7d84b32537a10d9bea1fd1bfc06577ef527 ] Add a stub for mt6359_accdet_enable_jack_detect() to prevent linker failures in the machine sound drivers calling it when CONFIG_SND_SOC_MT6359_ACCDET is not enabled. Suggested-by: AngeloGioacchino Del Regno Signed-off-by: Nícolas F. R. A. Prado Link: https://patch.msgid.link/20250306-mt8188-accdet-v3-3-7828e835ff4b@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e8358aa00ea7b7da60b840a5d817d56d5ee70d4a Author: Linus Walleij Date: Wed Mar 12 14:31:52 2025 +0100 ASoC: pcm6240: Drop bogus code handling IRQ as GPIO [ Upstream commit 17fdf318f5fbe5c27353ae917c0c5a2899d9c259 ] The current code for the IRQ in pcm6240 makes no sense: it looks up an IRQ with of_irq_get(), treat it as a GPIO by issuing gpio_request(), gpio_direction_input() and gpio_to_irq() on it. This is just wrong, if the device tree assigns the IRQ from a GPIO number this is just incorrect: it is clearly stated that GPIO providers and IRQ providers are orthogonal. It is possible to look up an IRQ to a corresponding GPIO line but this is taking an IRQ and pretending it's a GPIO, which is just semantically wrong. Drop the offending code and treat the IRQ that we get from the device tree as any other IRQ, see for example other codec drivers. The DT bindings for this codec does not have any in-tree DTS files, which may explain why things are weird. As a bonus, this moves the driver away from the legacy include. Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20250312-pcm-codecs-v1-3-41ffc4f8fc5c@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0076b0423b2cd799cccd527d6d2dd4824f03be70 Author: Sergio Perez Gonzalez Date: Sat Mar 15 23:46:06 2025 -0600 spi: spi-mux: Fix coverity issue, unchecked return value [ Upstream commit 5a5fc308418aca275a898d638bc38c093d101855 ] The return value of spi_setup() is not captured within spi_mux_select() and it is assumed to be always success. CID: 1638374 Signed-off-by: Sergio Perez Gonzalez Link: https://patch.msgid.link/20250316054651.13242-1-sperezglz@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b35ccfdc8573e4f130fcb4573e5980bc0ac5c4be Author: Gao Xiang Date: Mon Mar 17 13:48:40 2025 +0800 erofs: initialize decompression early [ Upstream commit fe1e57d44d7f106df9048e815e4862cf63921220 ] - Rename erofs_init_managed_cache() to z_erofs_init_super(); - Move the initialization of managed_pslots into z_erofs_init_super() too; - Move z_erofs_init_super() and packed inode preparation upwards, before the root inode initialization. Therefore, the root directory can also be compressible. Signed-off-by: Gao Xiang Acked-by: Chao Yu Link: https://lore.kernel.org/r/20250317054840.3483000-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit c8c643809f4a167cb2ec8cb80a768ac86b5433c5 Author: Mika Westerberg Date: Wed Mar 5 14:56:20 2025 +0200 thunderbolt: Do not add non-active NVM if NVM upgrade is disabled for retimer [ Upstream commit ad79c278e478ca8c1a3bf8e7a0afba8f862a48a1 ] This is only used to write a new NVM in order to upgrade the retimer firmware. It does not make sense to expose it if upgrade is disabled. This also makes it consistent with the router NVM upgrade. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 2585e6cbd96eb01ff3874b14512cb6d72abd8b64 Author: Josh Poimboeuf Date: Fri Mar 14 12:29:00 2025 -0700 objtool: Fix error handling inconsistencies in check() [ Upstream commit b745962cb97569aad026806bb0740663cf813147 ] Make sure all fatal errors are funneled through the 'out' label with a negative ret. Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Brendan Jackman Link: https://lore.kernel.org/r/0f49d6a27a080b4012e84e6df1e23097f44cc082.1741975349.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit a0d34b9be2bee42ae21d59153d21b3d1bf5b0d72 Author: Alexandre Belloni Date: Thu Mar 6 22:42:41 2025 +0100 rtc: rv3032: fix EERD location [ Upstream commit b0f9cb4a0706b0356e84d67e48500b77b343debe ] EERD is bit 2 in CTRL1 Link: https://lore.kernel.org/r/20250306214243.1167692-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit dab35f4921f854ba9ab92135c3cee56cfe2fb043 Author: Ilpo Järvinen Date: Wed Mar 5 23:38:41 2025 +0100 tcp: reorganize tcp_in_ack_event() and tcp_count_delivered() [ Upstream commit 149dfb31615e22271d2525f078c95ea49bc4db24 ] - Move tcp_count_delivered() earlier and split tcp_count_delivered_ce() out of it - Move tcp_in_ack_event() later - While at it, remove the inline from tcp_in_ack_event() and let the compiler to decide Accurate ECN's heuristics does not know if there is going to be ACE field based CE counter increase or not until after rtx queue has been processed. Only then the number of ACKed bytes/pkts is available. As CE or not affects presence of FLAG_ECE, that information for tcp_in_ack_event is not yet available in the old location of the call to tcp_in_ack_event(). Signed-off-by: Ilpo Järvinen Signed-off-by: Chia-Yu Chang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 50452704ecbad35a3e9239d88c3e48d438d3cc25 Author: Jan Kara Date: Thu Feb 6 10:46:59 2025 +0100 jbd2: do not try to recover wiped journal [ Upstream commit a662f3c03b754e1f97a2781fa242e95bdb139798 ] If a journal is wiped, we will set journal->j_tail to 0. However if 'write' argument is not set (as it happens for read-only device or for ocfs2), the on-disk superblock is not updated accordingly and thus jbd2_journal_recover() cat try to recover the wiped journal. Fix the check in jbd2_journal_recover() to use journal->j_tail for checking empty journal instead. Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250206094657.20865-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e2520cc19b7589819ae3614aaf07389910a9606b Author: Frank Li Date: Sat Mar 15 15:15:36 2025 -0500 PCI: dwc: Use resource start as ioremap() input in dw_pcie_pme_turn_off() [ Upstream commit 8f4a489b370e6612700aa16b9e4373b2d85d7503 ] The msg_res region translates writes into PCIe Message TLPs. Previously we mapped this region using atu.cpu_addr, the input address programmed into the ATU. "cpu_addr" is a misnomer because when a bus fabric translates addresses between the CPU and the ATU, the ATU input address is different from the CPU address. A future patch will rename "cpu_addr" and correct the value to be the ATU input address instead of the CPU physical address. Map the msg_res region before writing to it using the msg_res resource start, a CPU physical address. Link: https://lore.kernel.org/r/20250315201548.858189-2-helgaas@kernel.org Signed-off-by: Frank Li Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit e658f2d94a74cd4b4fc54875d89e34c68c318274 Author: Mykyta Yatsenko Date: Mon Mar 17 17:40:37 2025 +0000 bpf: Return prog btf_id without capable check [ Upstream commit 07651ccda9ff10a8ca427670cdd06ce2c8e4269c ] Return prog's btf_id from bpf_prog_get_info_by_fd regardless of capable check. This patch enables scenario, when freplace program, running from user namespace, requires to query target prog's btf. Signed-off-by: Mykyta Yatsenko Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20250317174039.161275-3-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin commit 66e8f1d64b1b06c458f0aee28c726ba229e8f87c Author: Alex Williamson Date: Tue Mar 11 17:06:21 2025 -0600 vfio/pci: Handle INTx IRQ_NOTCONNECTED [ Upstream commit 860be250fc32de9cb24154bf21b4e36f40925707 ] Some systems report INTx as not routed by setting pdev->irq to IRQ_NOTCONNECTED, resulting in a -ENOTCONN error when trying to setup eventfd signaling. Include this in the set of conditions for which the PIN register is virtualized to zero. Additionally consolidate vfio_pci_get_irq_count() to use this virtualized value in reporting INTx support via ioctl and sanity checking ioctl paths since pdev->irq is re-used when the device is in MSI mode. The combination of these results in both the config space of the device and the ioctl interface behaving as if the device does not support INTx. Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20250311230623.1264283-1-alex.williamson@redhat.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 0268f485aa69fe0814305c4f2a12a31c2f25c019 Author: Kai Mäkisara Date: Tue Mar 11 13:25:15 2025 +0200 scsi: st: ERASE does not change tape location [ Upstream commit ad77cebf97bd42c93ab4e3bffd09f2b905c1959a ] The SCSI ERASE command erases from the current position onwards. Don't clear the position variables. Signed-off-by: Kai Mäkisara Link: https://lore.kernel.org/r/20250311112516.5548-3-Kai.Makisara@kolumbus.fi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c6d366f8d24ffb94f4e5a88e4ad1edfed8f7ff63 Author: Kai Mäkisara Date: Tue Mar 11 13:25:16 2025 +0200 scsi: st: Tighten the page format heuristics with MODE SELECT [ Upstream commit 8db816c6f176321e42254badd5c1a8df8bfcfdb4 ] In the days when SCSI-2 was emerging, some drives did claim SCSI-2 but did not correctly implement it. The st driver first tries MODE SELECT with the page format bit set to set the block descriptor. If not successful, the non-page format is tried. The test only tests the sense code and this triggers also from illegal parameter in the parameter list. The test is limited to "old" devices and made more strict to remove false alarms. Signed-off-by: Kai Mäkisara Link: https://lore.kernel.org/r/20250311112516.5548-4-Kai.Makisara@kolumbus.fi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 853a4e7439ef1e2fea72e7eaa31ef9d11bf7e138 Author: Al Viro Date: Mon Mar 17 22:06:04 2025 -0400 hypfs_create_cpu_files(): add missing check for hypfs_mkdir() failure [ Upstream commit 00cdfdcfa0806202aea56b02cedbf87ef1e75df8 ] Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 94c3cbc69abbb14c22392fc9914917f01ef43b99 Author: Christian Göttsche Date: Sun Mar 2 17:06:39 2025 +0100 ext4: reorder capability check last [ Upstream commit 1b419c889c0767a5b66d0a6c566cae491f1cb0f7 ] capable() calls refer to enabled LSMs whether to permit or deny the request. This is relevant in connection with SELinux, where a capability check results in a policy decision and by default a denial message on insufficient permission is issued. It can lead to three undesired cases: 1. A denial message is generated, even in case the operation was an unprivileged one and thus the syscall succeeded, creating noise. 2. To avoid the noise from 1. the policy writer adds a rule to ignore those denial messages, hiding future syscalls, where the task performs an actual privileged operation, leading to hidden limited functionality of that task. 3. To avoid the noise from 1. the policy writer adds a rule to permit the task the requested capability, while it does not need it, violating the principle of least privilege. Signed-off-by: Christian Göttsche Reviewed-by: Serge Hallyn Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250302160657.127253-2-cgoettsche@seltendoof.de Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit a55ebe30f17a008773f024def37cf6c2595210ab Author: Alexandre Ghiti Date: Mon Jan 13 15:24:24 2025 +0100 riscv: Call secondary mmu notifier when flushing the tlb [ Upstream commit d9be2b9b60497a82aeceec3a98d8b37fdd2960f2 ] This is required to allow the IOMMU driver to correctly flush its own TLB. Reviewed-by: Clément Léger Reviewed-by: Samuel Holland Link: https://lore.kernel.org/r/20250113142424.30487-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 5cdd304662d548c0c171524baa9fab1cd0b25dd5 Author: shantiprasad shettar Date: Mon Mar 10 11:31:26 2025 -0700 bnxt_en: Query FW parameters when the CAPS_CHANGE bit is set [ Upstream commit a6c81e32aeacbfd530d576fa401edd506ec966ef ] Newer FW can set the CAPS_CHANGE flag during ifup if some capabilities or configurations have changed. For example, the CoS queue configurations may have changed. Support this new flag by treating it almost like FW reset. The driver will essentially rediscover all features and capabilities, reconfigure all backing store context memory, reset everything to default, and reserve all resources. Reviewed-by: Somnath Kotur Reviewed-by: Pavan Chebbi Signed-off-by: shantiprasad shettar Signed-off-by: Michael Chan Link: https://patch.msgid.link/20250310183129.3154117-5-michael.chan@broadcom.com Reviewed-by: Jacob Keller Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 34253084291cb210b251d64657958b8041ce4ab1 Author: Jeff Chen Date: Fri Mar 14 17:42:38 2025 +0800 wifi: mwifiex: Fix HT40 bandwidth issue. [ Upstream commit 4fcfcbe457349267fe048524078e8970807c1a5b ] This patch addresses an issue where, despite the AP supporting 40MHz bandwidth, the connection was limited to 20MHz. Without this fix, even if the access point supports 40MHz, the bandwidth after connection remains at 20MHz. This issue is not a regression. Signed-off-by: Jeff Chen Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20250314094238.2097341-1-jeff.chen_1@nxp.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 728945c962695ec5db95e44e9449f6b3edcccbcf Author: Tiwei Bie Date: Fri Feb 21 12:18:55 2025 +0800 um: Update min_low_pfn to match changes in uml_reserved [ Upstream commit e82cf3051e6193f61e03898f8dba035199064d36 ] When uml_reserved is updated, min_low_pfn must also be updated accordingly. Otherwise, min_low_pfn will not accurately reflect the lowest available PFN. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20250221041855.1156109-1-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d6d2f664cbf3b9bb99e5e5c41d32c567aa9cebd1 Author: Benjamin Berg Date: Mon Feb 24 19:18:19 2025 +0100 um: Store full CSGSFS and SS register from mcontext [ Upstream commit cef721e0d53d2b64f2ba177c63a0dfdd7c0daf17 ] Doing this allows using registers as retrieved from an mcontext to be pushed to a process using PTRACE_SETREGS. It is not entirely clear to me why CSGSFS was masked. Doing so creates issues when using the mcontext as process state in seccomp and simply copying the register appears to work perfectly fine for ptrace. Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250224181827.647129-2-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7790a9449cf4391b664775d444657deb2fa06b48 Author: Nick Hu Date: Wed Feb 19 19:41:35 2025 +0800 clocksource/drivers/timer-riscv: Stop stimecmp when cpu hotplug [ Upstream commit 70c93b026ed07078e933583591aa9ca6701cd9da ] Stop the timer when the cpu is going to be offline otherwise the timer interrupt may be pending while performing power-down. Suggested-by: Anup Patel Link: https://lore.kernel.org/lkml/20240829033904.477200-3-nick.hu@sifive.com/T/#u Signed-off-by: Nick Hu Reviewed-by: Anup Patel Acked-by: Daniel Lezcano Link: https://lore.kernel.org/r/20250219114135.27764-3-nick.hu@sifive.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 39ff1903246aa5f47c5cf741c705d649623a7103 Author: Heming Zhao Date: Mon Mar 10 15:36:21 2025 +0800 dlm: make tcp still work in multi-link env [ Upstream commit 03d2b62208a336a3bb984b9465ef6d89a046ea22 ] This patch bypasses multi-link errors in TCP mode, allowing dlm to operate on the first tcp link. Signed-off-by: Heming Zhao Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit f3ea633a111e0aba37ddb369b573386ec75fbad7 Author: Heiko Carstens Date: Mon Mar 10 12:42:59 2025 +0100 s390/tlb: Use mm_has_pgste() instead of mm_alloc_pgste() [ Upstream commit 9291ea091b29bb3e37c4b3416c7c1e49e472c7d5 ] An mm has pgstes only after s390_enable_sie() has been called, while mm_alloc_pgste() may be always true (e.g. via sysctl setting). Limit the calls to gmap_unlink() in pte_free_tlb() to those cases where there might be something to unlink. Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 1ea4653cff35c29d1dd0b14ad9c8245e7318f337 Author: Stanley Chu Date: Tue Mar 18 13:36:06 2025 +0800 i3c: master: svc: Fix missing STOP for master request [ Upstream commit 0430bf9bc1ac068c8b8c540eb93e5751872efc51 ] The controller driver nacked the master request but didn't emit a STOP to end the transaction. The driver shall refuse the unsupported requests and return the controller state to IDLE by emitting a STOP. Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250318053606.3087121-4-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 94206e0d72f7a6e0232ba4770912ac5569956098 Author: Alex Deucher Date: Thu Mar 13 20:52:38 2025 -0400 drm/amdgpu: adjust drm_firmware_drivers_only() handling [ Upstream commit e00e5c223878a60e391e5422d173c3382d378f87 ] Move to probe so we can check the PCI device type and only apply the drm_firmware_drivers_only() check for PCI DISPLAY classes. Also add a module parameter to override the nomodeset kernel parameter as a workaround for platforms that have this hardcoded on their kernel command lines. Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 85bda883a634c1efcb7b0392461ce5103196ee18 Author: Jing Zhou Date: Tue Mar 4 23:15:56 2025 +0800 drm/amd/display: Guard against setting dispclk low for dcn31x [ Upstream commit 9c2f4ae64bb6f6d83a54d88b9ee0f369cdbb9fa8 ] [WHY] We should never apply a minimum dispclk value while in prepare_bandwidth or while displays are active. This is always an optimizaiton for when all displays are disabled. [HOW] Defer dispclk optimization until safe_to_lower = true and display_count reaches 0. Since 0 has a special value in this logic (ie. no dispclk required) we also need adjust the logic that clamps it for the actual request to PMFW. Reviewed-by: Charlene Liu Reviewed-by: Chris Park Reviewed-by: Eric Yang Signed-off-by: Jing Zhou Signed-off-by: Nicholas Kazlauskas Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ca8fcb8bcef33aa2a624ee42cd373dc68294682b Author: Flora Cui Date: Fri Mar 14 10:27:55 2025 +0800 drm/amdgpu: release xcp_mgr on exit [ Upstream commit b5aaa82e2b12feaaa6958f7fa0917ddcc03c24ee ] Free on driver cleanup. Reviewed-by: Lijo Lazar Signed-off-by: Flora Cui Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a5a507fa5f223ad46766d3cca60ab5d819c71c4a Author: Chen Linxuan Date: Mon Mar 17 10:29:24 2025 +0800 blk-cgroup: improve policy registration error handling [ Upstream commit e1a0202c6bfda24002a3ae2115154fa90104c649 ] This patch improve the returned error code of blkcg_policy_register(). 1. Move the validation check for cpd/pd_alloc_fn and cpd/pd_free_fn function pairs to the start of blkcg_policy_register(). This ensures we immediately return -EINVAL if the function pairs are not correctly provided, rather than returning -ENOSPC after locking and unlocking mutexes unnecessarily. Those locks should not contention any problems, as error of policy registration is a super cold path. 2. Return -ENOMEM when cpd_alloc_fn() failed. Co-authored-by: Wen Tao Signed-off-by: Wen Tao Signed-off-by: Chen Linxuan Reviewed-by: Michal Koutný Acked-by: Tejun Heo Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/3E333A73B6B6DFC0+20250317022924.150907-1-chenlinxuan@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c60f8684a81181a7b8efb25abf65831b7fb4bffe Author: Filipe Manana Date: Wed Feb 5 13:09:25 2025 +0000 btrfs: send: return -ENAMETOOLONG when attempting a path that is too long [ Upstream commit a77749b3e21813566cea050bbb3414ae74562eba ] When attempting to build a too long path we are currently returning -ENOMEM, which is very odd and misleading. So update fs_path_ensure_buf() to return -ENAMETOOLONG instead. Also, while at it, move the WARN_ON() into the if statement's expression, as it makes it clear what is being tested and also has the effect of adding 'unlikely' to the statement, which allows the compiler to generate better code as this condition is never expected to happen. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c4845a09a1edd1d4b629770f9d937c345ce65362 Author: Filipe Manana Date: Fri Feb 21 16:12:15 2025 +0000 btrfs: get zone unusable bytes while holding lock at btrfs_reclaim_bgs_work() [ Upstream commit 1283b8c125a83bf7a7dbe90c33d3472b6d7bf612 ] At btrfs_reclaim_bgs_work(), we are grabbing a block group's zone unusable bytes while not under the protection of the block group's spinlock, so this can trigger race reports from KCSAN (or similar tools) since that field is typically updated while holding the lock, such as at __btrfs_add_free_space_zoned() for example. Fix this by grabbing the zone unusable bytes while we are still in the critical section holding the block group's spinlock, which is right above where we are currently grabbing it. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0058c61d47ee15778caaa4a487d00c63b39265d4 Author: Filipe Manana Date: Thu Mar 6 14:25:38 2025 +0000 btrfs: fix non-empty delayed iputs list on unmount due to async workers [ Upstream commit cda76788f8b0f7de3171100e3164ec1ce702292e ] At close_ctree() after we have ran delayed iputs either explicitly through calling btrfs_run_delayed_iputs() or later during the call to btrfs_commit_super() or btrfs_error_commit_super(), we assert that the delayed iputs list is empty. We have (another) race where this assertion might fail because we have queued an async write into the fs_info->workers workqueue. Here's how it happens: 1) We are submitting a data bio for an inode that is not the data relocation inode, so we call btrfs_wq_submit_bio(); 2) btrfs_wq_submit_bio() submits a work for the fs_info->workers queue that will run run_one_async_done(); 3) We enter close_ctree(), flush several work queues except fs_info->workers, explicitly run delayed iputs with a call to btrfs_run_delayed_iputs() and then again shortly after by calling btrfs_commit_super() or btrfs_error_commit_super(), which also run delayed iputs; 4) run_one_async_done() is executed in the work queue, and because there was an IO error (bio->bi_status is not 0) it calls btrfs_bio_end_io(), which drops the final reference on the associated ordered extent by calling btrfs_put_ordered_extent() - and that adds a delayed iput for the inode; 5) At close_ctree() we find that after stopping the cleaner and transaction kthreads the delayed iputs list is not empty, failing the following assertion: ASSERT(list_empty(&fs_info->delayed_iputs)); Fix this by flushing the fs_info->workers workqueue before running delayed iputs at close_ctree(). David reported this when running generic/648, which exercises IO error paths by using the DM error table. Reported-by: David Sterba Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8629f9d9a92e8e64a426b0492630f45a8eef89e5 Author: Qu Wenruo Date: Fri Mar 7 14:36:10 2025 +1030 btrfs: run btrfs_error_commit_super() early [ Upstream commit df94a342efb451deb0e32b495d1d6cd4bb3a1648 ] [BUG] Even after all the error fixes related the "ASSERT(list_empty(&fs_info->delayed_iputs));" in close_ctree(), I can still hit it reliably with my experimental 2K block size. [CAUSE] In my case, all the error is triggered after the fs is already in error status. I find the following call trace to be the cause of race: Main thread | endio_write_workers ---------------------------------------------+--------------------------- close_ctree() | |- btrfs_error_commit_super() | | |- btrfs_cleanup_transaction() | | | |- btrfs_destroy_all_ordered_extents() | | | |- btrfs_wait_ordered_roots() | | |- btrfs_run_delayed_iputs() | | | btrfs_finish_ordered_io() | | |- btrfs_put_ordered_extent() | | |- btrfs_add_delayed_iput() |- ASSERT(list_empty(delayed_iputs)) | !!! Triggered !!! The root cause is that, btrfs_wait_ordered_roots() only wait for ordered extents to finish their IOs, not to wait for them to finish and removed. [FIX] Since btrfs_error_commit_super() will flush and wait for all ordered extents, it should be executed early, before we start flushing the workqueues. And since btrfs_error_commit_super() now runs early, there is no need to run btrfs_run_delayed_iputs() inside it, so just remove the btrfs_run_delayed_iputs() call from btrfs_error_commit_super(). Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a4840945f514c227d9cb8925f06c230c71b90d3c Author: Mark Harmstone Date: Thu Mar 6 10:58:46 2025 +0000 btrfs: avoid linker error in btrfs_find_create_tree_block() [ Upstream commit 7ef3cbf17d2734ca66c4ed8573be45f4e461e7ee ] The inline function btrfs_is_testing() is hardcoded to return 0 if CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set. Currently we're relying on the compiler optimizing out the call to alloc_test_extent_buffer() in btrfs_find_create_tree_block(), as it's not been defined (it's behind an #ifdef). Add a stub version of alloc_test_extent_buffer() to avoid linker errors on non-standard optimization levels. This problem was seen on GCC 14 with -O0 and is helps to see symbols that would be otherwise optimized out. Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1144874b41dcd69ef33704454175bfdd060b28fc Author: Boris Burkov Date: Mon Mar 3 15:01:05 2025 -0800 btrfs: make btrfs_discard_workfn() block_group ref explicit [ Upstream commit 895c6721d310c036dcfebb5ab845822229fa35eb ] Currently, the async discard machinery owns a ref to the block_group when the block_group is queued on a discard list. However, to handle races with discard cancellation and the discard workfn, we have a specific logic to detect that the block_group is *currently* running in the workfn, to protect the workfn's usage amidst cancellation. As far as I can tell, this doesn't have any overt bugs (though finish_discard_pass() and remove_from_discard_list() racing can have a surprising outcome for the caller of remove_from_discard_list() in that it is again added at the end). But it is needlessly complicated to rely on locking and the nullity of discard_ctl->block_group. Simplify this significantly by just taking a refcount while we are in the workfn and unconditionally drop it in both the remove and workfn paths, regardless of if they race. Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 477a412a2f6cc411a40d79293448a9345689e6a0 Author: Vitalii Mordan Date: Wed Feb 12 20:28:03 2025 +0300 i2c: pxa: fix call balance of i2c->clk handling routines [ Upstream commit be7113d2e2a6f20cbee99c98d261a1fd6fd7b549 ] If the clock i2c->clk was not enabled in i2c_pxa_probe(), it should not be disabled in any path. Found by Linux Verification Center (linuxtesting.org) with Klever. Signed-off-by: Vitalii Mordan Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20250212172803.1422136-1-mordan@ispras.ru Signed-off-by: Sasha Levin commit 3b9cf1c0fafa2cb0ca40ffd9786e1c83175bbef9 Author: Stephan Gerhold Date: Tue Nov 28 10:48:37 2023 +0100 i2c: qup: Vote for interconnect bandwidth to DRAM [ Upstream commit d4f35233a6345f62637463ef6e0708f44ffaa583 ] When the I2C QUP controller is used together with a DMA engine it needs to vote for the interconnect path to the DRAM. Otherwise it may be unable to access the memory quickly enough. The requested peak bandwidth is dependent on the I2C core clock. To avoid sending votes too often the bandwidth is always requested when a DMA transfer starts, but dropped only on runtime suspend. Runtime suspend should only happen if no transfer is active. After resumption we can defer the next vote until the first DMA transfer actually happens. The implementation is largely identical to the one introduced for spi-qup in commit ecdaa9473019 ("spi: qup: Vote for interconnect bandwidth to DRAM") since both drivers represent the same hardware block. Signed-off-by: Stephan Gerhold Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20231128-i2c-qup-dvfs-v1-3-59a0e3039111@kernkonzept.com Signed-off-by: Sasha Levin commit c6f2694c580c27dca0cf7546ee9b4bfa6b940e38 Author: Philip Redkin Date: Fri Nov 15 20:36:59 2024 +0300 x86/mm: Check return value from memblock_phys_alloc_range() [ Upstream commit 631ca8909fd5c62b9fda9edda93924311a78a9c4 ] At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblock_phys_alloc_range() returns 0 on failure, which leads memblock_phys_free() to throw the first 4 MiB of physical memory to the wolves. At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation. Signed-off-by: Philip Redkin Signed-off-by: Ingo Molnar Cc: Dave Hansen Cc: Rik van Riel Cc: "H. Peter Anvin" Link: https://lore.kernel.org/r/94b3e98f-96a7-3560-1f76-349eb95ccf7f@rarity.fan Signed-off-by: Sasha Levin commit d0f987525744098061e6093dbc266b841b5cf1bb Author: Sohil Mehta Date: Wed Feb 19 18:41:21 2025 +0000 x86/microcode: Update the Intel processor flag scan check [ Upstream commit 7e6b0a2e4152f4046af95eeb46f8b4f9b2a7398d ] The Family model check to read the processor flag MSR is misleading and potentially incorrect. It doesn't consider Family while comparing the model number. The original check did have a Family number but it got lost/moved during refactoring. intel_collect_cpu_info() is called through multiple paths such as early initialization, CPU hotplug as well as IFS image load. Some of these flows would be error prone due to the ambiguous check. Correct the processor flag scan check to use a Family number and update it to a VFM based one to make it more readable. Signed-off-by: Sohil Mehta Signed-off-by: Ingo Molnar Acked-by: Dave Hansen Link: https://lore.kernel.org/r/20250219184133.816753-4-sohil.mehta@intel.com Signed-off-by: Sasha Levin commit 8973fb71c9269f54f4ea4b218c8466b5adea8a97 Author: Sohil Mehta Date: Wed Feb 19 18:41:28 2025 +0000 x86/smpboot: Fix INIT delay assignment for extended Intel Families [ Upstream commit 7a2ad752746bfb13e89a83984ecc52a48bae4969 ] Some old crusty CPUs need an extra delay that slows down booting. See the comment above 'init_udelay' for details. Newer CPUs don't need the delay. Right now, for Intel, Family 6 and only Family 6 skips the delay. That leaves out both the Family 15 (Pentium 4s) and brand new Family 18/19 models. The omission of Family 15 (Pentium 4s) seems like an oversight and 18/19 do not need the delay. Skip the delay on all Intel processors Family 6 and beyond. Signed-off-by: Sohil Mehta Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250219184133.816753-11-sohil.mehta@intel.com Signed-off-by: Sasha Levin commit 44e041675383b198e4050177df372361a872147b Author: Ingo Molnar Date: Wed Mar 12 12:48:49 2025 +0100 x86/stackprotector/64: Only export __ref_stack_chk_guard on CONFIG_SMP [ Upstream commit 91d5451d97ce35cbd510277fa3b7abf9caa4e34d ] The __ref_stack_chk_guard symbol doesn't exist on UP: :4:15: error: ‘__ref_stack_chk_guard’ undeclared here (not in a function) Fix the #ifdef around the entry.S export. Signed-off-by: Ingo Molnar Cc: Brian Gerst Cc: Ard Biesheuvel Cc: Uros Bizjak Link: https://lore.kernel.org/r/20250123190747.745588-8-brgerst@gmail.com Signed-off-by: Sasha Levin commit 63b7dade892b605af3df7be0ce195b6f4bc5fbe7 Author: Thomas Huth Date: Mon Mar 10 11:42:56 2025 +0100 x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in UAPI headers [ Upstream commit 8a141be3233af7d4f7014ebc44d5452d46b2b1be ] __ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for UAPI headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. Signed-off-by: Thomas Huth Signed-off-by: Ingo Molnar Cc: "H. Peter Anvin" Cc: Linus Torvalds Cc: Kees Cook Cc: Brian Gerst Link: https://lore.kernel.org/r/20250310104256.123527-1-thuth@redhat.com Signed-off-by: Sasha Levin commit ac3af695c4b001b0dfdb311f2b4cfb81b1d3d54c Author: Quan Zhou Date: Tue Jan 14 13:06:22 2025 +0800 wifi: mt76: mt7925: fix fails to enter low power mode in suspend state [ Upstream commit 2d5630b0c9466ac6549495828aa7dce7424a272a ] The mt7925 sometimes fails to enter low power mode during suspend. This is caused by the chip firmware sending an additional ACK event to the host after processing the suspend command. Due to timing issues, this event may not reach the host, causing the chip to get stuck. To resolve this, the ACK flag in the suspend command is removed, as it is not needed in the MT7925 architecture. This prevents the firmware from sending the additional ACK event, ensuring the device can reliably enter low power mode during suspend. Signed-off-by: Quan Zhou Link: https://patch.msgid.link/d056938144a3a0336c3a4e3cec6f271899f32bf7.1736775666.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8b526e4d944ae8ad95d48e39cb6a53b2201bd6e9 Author: Ming Yen Hsieh Date: Tue Mar 4 19:36:44 2025 +0800 wifi: mt76: mt7925: load the appropriate CLC data based on hardware type [ Upstream commit f2027ef3f733d3f0bb7f27fa3343784058f946ab ] Read the EEPROM to determine the hardware type and uses this to load the correct CLC data. Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250304113649.867387-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c9c64da88e38df74d04cd148a04949a796c4fe9f Author: Benjamin Lin Date: Tue Mar 11 11:36:38 2025 +0100 wifi: mt76: mt7996: revise TXS size [ Upstream commit 593c829b4326f7b3b15a69e97c9044ecbad3c319 ] Size of MPDU/PPDU TXS is 12 DWs. In mt7996/mt7992, last 4 DWs are reserved, so TXS size was mistakenly considered to be 8 DWs. However, in mt7990, 9th DW of TXS starts to be used. Signed-off-by: Benjamin Lin Link: https://patch.msgid.link/20250311103646.43346-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1d58321192052a66a8dddfbd3d829ea52a9fb094 Author: Rex Lu Date: Tue Mar 11 11:36:39 2025 +0100 wifi: mt76: mt7996: fix SER reset trigger on WED reset [ Upstream commit 8d38abdf6c182225c5c0a81451fa51b7b36a635d ] The firmware needs a specific trigger when WED is being reset due to an ethernet reset condition. This helps prevent further L1 SER failure. Signed-off-by: Rex Lu Link: https://patch.msgid.link/20250311103646.43346-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fa6c05122fb82a9dd5d24a5f7c0e70ee31f872d5 Author: Felix Fietkau Date: Tue Mar 11 11:36:43 2025 +0100 wifi: mt76: only mark tx-status-failed frames as ACKed on mt76x0/2 [ Upstream commit 0c5a89ceddc1728a40cb3313948401dd70e3c649 ] The interrupt status polling is unreliable, which can cause status events to get lost. On all newer chips, txs-timeout is an indication that the packet was either never sent, or never acked. Fixes issues with inactivity polling. Link: https://patch.msgid.link/20250311103646.43346-6-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8f82cf305efd6bf32e9e9d6579e11321dc9c10c5 Author: Eric Dumazet Date: Wed Mar 19 00:13:30 2025 -0700 cgroup/rstat: avoid disabling irqs for O(num_cpu) [ Upstream commit 0efc297a3c4974dbd609ee36fc6345720b6ca735 ] cgroup_rstat_flush_locked() grabs the irq safe cgroup_rstat_lock while iterating all possible cpus. It only drops the lock if there is scheduler or spin lock contention. If neither, then interrupts can be disabled for a long time. On large machines this can disable interrupts for a long enough time to drop network packets. On 400+ CPU machines I've seen interrupt disabled for over 40 msec. Prevent rstat from disabling interrupts while processing all possible cpus. Instead drop and reacquire cgroup_rstat_lock for each cpu. This approach was previously discussed in https://lore.kernel.org/lkml/ZBz%2FV5a7%2F6PZeM7S@slm.duckdns.org/, though this was in the context of an non-irq rstat spin lock. Benchmark this change with: 1) a single stat_reader process with 400 threads, each reading a test memcg's memory.stat repeatedly for 10 seconds. 2) 400 memory hog processes running in the test memcg and repeatedly charging memory until oom killed. Then they repeat charging and oom killing. v6.14-rc6 with CONFIG_IRQSOFF_TRACER with stat_reader and hogs, finds interrupts are disabled by rstat for 45341 usec: # => started at: _raw_spin_lock_irq # => ended at: cgroup_rstat_flush # # # _------=> CPU# # / _-----=> irqs-off/BH-disabled # | / _----=> need-resched # || / _---=> hardirq/softirq # ||| / _--=> preempt-depth # |||| / _-=> migrate-disable # ||||| / delay # cmd pid |||||| time | caller # \ / |||||| \ | / stat_rea-96532 52d.... 0us*: _raw_spin_lock_irq stat_rea-96532 52d.... 45342us : cgroup_rstat_flush stat_rea-96532 52d.... 45342us : tracer_hardirqs_on <-cgroup_rstat_flush stat_rea-96532 52d.... 45343us : => memcg1_stat_format => memory_stat_format => memory_stat_show => seq_read_iter => vfs_read => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe With this patch the CONFIG_IRQSOFF_TRACER doesn't find rstat to be the longest holder. The longest irqs-off holder has irqs disabled for 4142 usec, a huge reduction from previous 45341 usec rstat finding. Running stat_reader memory.stat reader for 10 seconds: - without memory hogs: 9.84M accesses => 12.7M accesses - with memory hogs: 9.46M accesses => 11.1M accesses The throughput of memory.stat access improves. The mode of memory.stat access latency after grouping by of 2 buckets: - without memory hogs: 64 usec => 16 usec - with memory hogs: 64 usec => 8 usec The memory.stat latency improves. Signed-off-by: Eric Dumazet Signed-off-by: Greg Thelen Tested-by: Greg Thelen Acked-by: Michal Koutný Reviewed-by: Yosry Ahmed Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit dca76ee1f02ae896a3e6d869fa26551b2ef78154 Author: Victor Skvortsov Date: Mon Mar 17 09:32:13 2025 -0400 drm/amdgpu: Skip pcie_replay_count sysfs creation for VF [ Upstream commit 9c05636ca72a2dbf41bf0900380f438a0de47319 ] VFs cannot read the NAK_COUNTER register. This information is only available through PMFW metrics. Signed-off-by: Victor Skvortsov Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 67bb2175095eb1510c0282ae3ebc0079722a8cbc Author: Erick Shepherd Date: Fri Mar 14 14:50:21 2025 -0500 mmc: host: Wait for Vdd to settle on card power off [ Upstream commit 31e75ed964582257f59156ce6a42860e1ae4cc39 ] The SD spec version 6.0 section 6.4.1.5 requires that Vdd must be lowered to less than 0.5V for a minimum of 1 ms when powering off a card. Increase wait to 15 ms so that voltage has time to drain down to 0.5V and cards can power off correctly. Issues with voltage drain time were only observed on Apollo Lake and Bay Trail host controllers so this fix is limited to those devices. Signed-off-by: Erick Shepherd Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20250314195021.1588090-1-erick.shepherd@ni.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 4005036642a27463b875f3b03d3b06cf953d0e30 Author: Stefan Wahren Date: Sun Mar 9 13:50:13 2025 +0100 staging: vchiq_arm: Create keep-alive thread during probe [ Upstream commit 86bc8821700665ad3962f3ef0d93667f59cf7031 ] Creating the keep-alive thread in vchiq_platform_init_state have the following advantages: - abort driver probe if kthread_create fails (more consistent behavior) - make resource release process easier Since vchiq_keepalive_thread_func is defined below vchiq_platform_init_state, the latter must be moved. Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250309125014.37166-5-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 123bcd8f42b7ecc6cb81ed295dbea76840e649e6 Author: Christian Brauner Date: Thu Mar 20 14:24:08 2025 +0100 pidfs: improve multi-threaded exec and premature thread-group leader exit polling [ Upstream commit 0fb482728ba1ee2130eaa461bf551f014447997c ] This is another attempt trying to make pidfd polling for multi-threaded exec and premature thread-group leader exit consistent. A quick recap of these two cases: (1) During a multi-threaded exec by a subthread, i.e., non-thread-group leader thread, all other threads in the thread-group including the thread-group leader are killed and the struct pid of the thread-group leader will be taken over by the subthread that called exec. IOW, two tasks change their TIDs. (2) A premature thread-group leader exit means that the thread-group leader exited before all of the other subthreads in the thread-group have exited. Both cases lead to inconsistencies for pidfd polling with PIDFD_THREAD. Any caller that holds a PIDFD_THREAD pidfd to the current thread-group leader may or may not see an exit notification on the file descriptor depending on when poll is performed. If the poll is performed before the exec of the subthread has concluded an exit notification is generated for the old thread-group leader. If the poll is performed after the exec of the subthread has concluded no exit notification is generated for the old thread-group leader. The correct behavior would be to simply not generate an exit notification on the struct pid of a subhthread exec because the struct pid is taken over by the subthread and thus remains alive. But this is difficult to handle because a thread-group may exit prematurely as mentioned in (2). In that case an exit notification is reliably generated but the subthreads may continue to run for an indeterminate amount of time and thus also may exec at some point. So far there was no way to distinguish between (1) and (2) internally. This tiny series tries to address this problem by discarding PIDFD_THREAD notification on premature thread-group leader exit. If that works correctly then no exit notifications are generated for a PIDFD_THREAD pidfd for a thread-group leader until all subthreads have been reaped. If a subthread should exec aftewards no exit notification will be generated until that task exits or it creates subthreads and repeates the cycle. Co-Developed-by: Oleg Nesterov Signed-off-by: Oleg Nesterov Link: https://lore.kernel.org/r/20250320-work-pidfs-thread_group-v4-1-da678ce805bf@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 1d1e1efad1cf049e888bf175a5c6be85d792620c Author: Robert Richter Date: Thu Mar 20 12:22:22 2025 +0100 libnvdimm/labels: Fix divide error in nd_label_data_init() [ Upstream commit ef1d3455bbc1922f94a91ed58d3d7db440652959 ] If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check. Signed-off-by: Robert Richter Reviewed-by: Pankaj Gupta Reviewed-by: Ira Weiny Link: https://patch.msgid.link/20250320112223.608320-1-rrichter@amd.com Signed-off-by: Ira Weiny Signed-off-by: Sasha Levin commit 37ac2434aae16b4a36fec163edc2928a7acf599c Author: Nicolas Bretz Date: Wed Mar 19 11:10:11 2025 -0600 ext4: on a remount, only log the ro or r/w state when it has changed [ Upstream commit d7b0befd09320e3356a75cb96541c030515e7f5f ] A user complained that a message such as: EXT4-fs (nvme0n1p3): re-mounted UUID ro. Quota mode: none. implied that the file system was previously mounted read/write and was now remounted read-only, when it could have been some other mount state that had changed by the "mount -o remount" operation. Fix this by only logging "ro"or "r/w" when it has changed. https://bugzilla.kernel.org/show_bug.cgi?id=219132 Signed-off-by: Nicolas Bretz Link: https://patch.msgid.link/20250319171011.8372-1-bretznic@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3e10592b477ec6e8ea49d8a6c0d52dcb57fa79d0 Author: Roger Pau Monne Date: Wed Feb 19 10:20:55 2025 +0100 xen/pci: Do not register devices with segments >= 0x10000 [ Upstream commit 5ccf1b8ae76ddf348e02a0d1564ff9baf8b6c415 ] The current hypercall interface for doing PCI device operations always uses a segment field that has a 16 bit width. However on Linux there are buses like VMD that hook up devices into the PCI hierarchy at segment >= 0x10000, after the maximum possible segment enumerated in ACPI. Attempting to register or manage those devices with Xen would result in errors at best, or overlaps with existing devices living on the truncated equivalent segment values. Note also that the VMD segment numbers are arbitrarily assigned by the OS, and hence there would need to be some negotiation between Xen and the OS to agree on how to enumerate VMD segments and devices behind them. Skip notifying Xen about those devices. Given how VMD bridges can multiplex interrupts on behalf of devices behind them there's no need for Xen to be aware of such devices for them to be usable by Linux. Signed-off-by: Roger Pau Monné Acked-by: Juergen Gross Message-ID: <20250219092059.90850-2-roger.pau@citrix.com> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 2a8bedeb963f04d13b782e099c7db3d2f62a056e Author: Roger Pau Monne Date: Wed Feb 19 10:20:56 2025 +0100 PCI: vmd: Disable MSI remapping bypass under Xen [ Upstream commit 6c4d5aadf5df31ea0ac025980670eee9beaf466b ] MSI remapping bypass (directly configuring MSI entries for devices on the VMD bus) won't work under Xen, as Xen is not aware of devices in such bus, and hence cannot configure the entries using the pIRQ interface in the PV case, and in the PVH case traps won't be setup for MSI entries for such devices. Until Xen is aware of devices in the VMD bus prevent the VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any kind of Xen guest. The MSI remapping bypass is an optional feature of VMD bridges, and hence when running under Xen it will be masked and devices will be forced to redirect its interrupts from the VMD bridge. That mode of operation must always be supported by VMD bridges and works when Xen is not aware of devices behind the VMD bridge. Signed-off-by: Roger Pau Monné Acked-by: Bjorn Helgaas Message-ID: <20250219092059.90850-3-roger.pau@citrix.com> Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 8b80fd3f76f2a641c76fbda45b9ca4e1eddfc763 Author: Jonathan Kim Date: Fri Mar 14 11:08:21 2025 -0400 drm/amdkfd: set precise mem ops caps to disabled for gfx 11 and 12 [ Upstream commit f82d27dcff939d3cbecbc60e1b71e2518c37e81d ] Clause instructions with precise memory enabled currently hang the shader so set capabilities flag to disabled since it's unsafe to use for debugging. Signed-off-by: Jonathan Kim Tested-by: Lancelot Six Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 98e38fe7d355765f6665013d6379b4415d56b897 Author: Flora Cui Date: Thu Feb 27 10:39:27 2025 +0800 drm/amdgpu/discovery: check ip_discovery fw file available [ Upstream commit 017fbb6690c2245b1b4ef39b66c79d2990fe63dd ] Signed-off-by: Flora Cui Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1630224189cc43768669d60412460118ebcb74b4 Author: Trond Myklebust Date: Thu Mar 20 12:45:01 2025 -0400 pNFS/flexfiles: Report ENETDOWN as a connection error [ Upstream commit aa42add73ce9b9e3714723d385c254b75814e335 ] If the client should see an ENETDOWN when trying to connect to the data server, it might still be able to talk to the metadata server through another NIC. If so, report the error. Signed-off-by: Trond Myklebust Reviewed-by: Jeff Layton Tested-by: Jeff Layton Acked-by: Chuck Lever Signed-off-by: Sasha Levin commit a1596965a7c828cca581df4cbf178d405d440671 Author: Ian Rogers Date: Tue Mar 11 14:36:23 2025 -0700 tools/build: Don't pass test log files to linker [ Upstream commit 935e7cb5bb80106ff4f2fe39640f430134ef8cd8 ] Separate test log files from object files. Depend on test log output but don't pass to the linker. Reviewed-by: James Clark Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250311213628.569562-2-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2780aa8394415df0a69e3b908d6dd8c79e1d1bcc Author: ChunHao Lin Date: Tue Mar 18 16:37:21 2025 +0800 r8169: disable RTL8126 ZRX-DC timeout [ Upstream commit b48688ea3c9ac8d5d910c6e91fb7f80d846581f0 ] Disable it due to it dose not meet ZRX-DC specification. If it is enabled, device will exit L1 substate every 100ms. Disable it for saving more power in L1 substate. Signed-off-by: ChunHao Lin Reviewed-by: Heiner Kallweit Link: https://patch.msgid.link/20250318083721.4127-3-hau@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e63b634806a1d64bb2c8ca15b0c75d13d861c4de Author: Frank Li Date: Sat Mar 15 15:15:46 2025 -0500 PCI: dwc: ep: Ensure proper iteration over outbound map windows [ Upstream commit f3e1dccba0a0833fc9a05fb838ebeb6ea4ca0e1a ] Most systems' PCIe outbound map windows have non-zero physical addresses, but the possibility of encountering zero increased after following commit ("PCI: dwc: Use parent_bus_offset"). 'ep->outbound_addr[n]', representing 'parent_bus_address', might be 0 on some hardware, which trims high address bits through bus fabric before sending to the PCIe controller. Replace the iteration logic with 'for_each_set_bit()' to ensure only allocated map windows are iterated when determining the ATU index from a given address. Link: https://lore.kernel.org/r/20250315201548.858189-12-helgaas@kernel.org Signed-off-by: Frank Li Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit c0c59a1f776654aded96a9237398bf1a00f31faf Author: Josh Poimboeuf Date: Mon Mar 24 14:55:58 2025 -0700 objtool: Properly disable uaccess validation [ Upstream commit e1a9dda74dbffbc3fa2069ff418a1876dc99fb14 ] If opts.uaccess isn't set, the uaccess validation is disabled, but only partially: it doesn't read the uaccess_safe_builtin list but still tries to do the validation. Disable it completely to prevent false warnings. Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/0e95581c1d2107fb5f59418edf2b26bba38b0cbb.1742852846.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit ac30595154da094de222f3648243ad000596a421 Author: Ryo Takakura Date: Fri Mar 21 07:33:22 2025 -0700 lockdep: Fix wait context check on softirq for PREEMPT_RT [ Upstream commit 61c39d8c83e2077f33e0a2c8980a76a7f323f0ce ] Since: 0c1d7a2c2d32 ("lockdep: Remove softirq accounting on PREEMPT_RT.") the wait context test for mutex usage within "in softirq context" fails as it references @softirq_context: | wait context tests | -------------------------------------------------------------------------- | rcu | raw | spin |mutex | -------------------------------------------------------------------------- in hardirq context: ok | ok | ok | ok | in hardirq context (not threaded): ok | ok | ok | ok | in softirq context: ok | ok | ok |FAILED| As a fix, add lockdep map for BH disabled section. This fixes the issue by letting us catch cases when local_bh_disable() gets called with preemption disabled where local_lock doesn't get acquired. In the case of "in softirq context" selftest, local_bh_disable() was being called with preemption disable as it's early in the boot. [ boqun: Move the lockdep annotations into __local_bh_*() to avoid false positives because of unpaired local_bh_disable() reported by Borislav Petkov and Peter Zijlstra, and make bh_lock_map only exist for PREEMPT_RT. ] [ mingo: Restored authorship and improved the bh_lock_map definition. ] Signed-off-by: Ryo Takakura Signed-off-by: Boqun Feng Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250321143322.79651-1-boqun.feng@gmail.com Signed-off-by: Sasha Levin commit 44b79041c44aed132b504c6045541649677fb3f4 Author: Jing Su Date: Wed Mar 19 16:57:51 2025 +0800 dql: Fix dql->limit value when reset. [ Upstream commit 3a17f23f7c36bac3a3584aaf97d3e3e0b2790396 ] Executing dql_reset after setting a non-zero value for limit_min can lead to an unreasonable situation where dql->limit is less than dql->limit_min. For instance, after setting /sys/class/net/eth*/queues/tx-0/byte_queue_limits/limit_min, an ifconfig down/up operation might cause the ethernet driver to call netdev_tx_reset_queue, which in turn invokes dql_reset. In this case, dql->limit is reset to 0 while dql->limit_min remains non-zero value, which is unexpected. The limit should always be greater than or equal to limit_min. Signed-off-by: Jing Su Link: https://patch.msgid.link/Z9qHD1s/NEuQBdgH@pilot-ThinkCentre-M930t-N000 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f48ee562c095e552a30b8d9cc0566a267b410f8a Author: Pedro Nishiyama Date: Sat Mar 1 03:23:00 2025 -0300 Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken [ Upstream commit 14d17c78a4b1660c443bae9d38c814edea506f62 ] A SCO connection without the proper voice_setting can cause the controller to lock up. Signed-off-by: Pedro Nishiyama Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7ec409ee15ac18f3518be17d99ac6e16c3f70f60 Author: Sean Wang Date: Tue Mar 11 18:25:22 2025 -0700 Bluetooth: btmtksdio: Prevent enabling interrupts after IRQ handler removal [ Upstream commit 6ac4233afb9a389a7629b7f812395d1d1eca5a83 ] Ensure interrupts are not re-enabled when the IRQ handler has already been removed. This prevents unexpected IRQ handler execution due to stale or unhandled interrupts. Modify btmtksdio_txrx_work to check if bdev->func->irq_handler exists before calling sdio_writel to enable interrupts. Co-developed-by: Pedro Tsai Signed-off-by: Pedro Tsai Co-developed-by: Felix Freimann Signed-off-by: Felix Freimann Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7cfde2a48280086a23e4ec59bfb591ed2942061a Author: Alice Guo Date: Mon Dec 9 11:48:59 2024 -0500 thermal/drivers/qoriq: Power down TMU on system suspend [ Upstream commit 229f3feb4b0442835b27d519679168bea2de96c2 ] Enable power-down of TMU (Thermal Management Unit) for TMU version 2 during system suspend to save power. Save approximately 4.3mW on VDD_ANA_1P8 on i.MX93 platforms. Signed-off-by: Alice Guo Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241209164859.3758906-2-Frank.Li@nxp.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit c347928320080be70e389a6daf7c28322ea24238 Author: Nícolas F. R. A. Prado Date: Mon Jan 13 10:27:15 2025 -0300 thermal/drivers/mediatek/lvts: Start sensor interrupts disabled [ Upstream commit 2738fb3ec6838a10d2c4ce65cefdb3b90b11bd61 ] Interrupts are enabled per sensor in lvts_update_irq_mask() as needed, there's no point in enabling all of them during initialization. Change the MONINT register initial value so all sensor interrupts start disabled. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20250113-mt8192-lvts-filtered-suspend-fix-v2-4-07a25200c7c6@collabora.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 7b32d4e62c87115bf878f9d4b64624eccb336819 Author: Hans-Frieder Vogt Date: Sat Mar 22 11:45:56 2025 +0100 net: tn40xx: create swnode for mdio and aqr105 phy and add to mdiobus [ Upstream commit 25b6a6d29d4082f6ac231c056ac321a996eb55c9 ] In case of an AQR105-based device, create a software node for the mdio function, with a child node for the Aquantia AQR105 PHY, providing a firmware-name (and a bit more, which may be used for future checks) to allow the PHY to load a MAC specific firmware from the file system. The name of the PHY software node follows the naming convention suggested in the patch for the mdiobus_scan function (in the same patch series). Signed-off-by: Hans-Frieder Vogt Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250322-tn9510-v3a-v7-5-672a9a3d8628@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b07ba838aded8b710c65706018da148aa405f070 Author: Hans-Frieder Vogt Date: Sat Mar 22 11:45:58 2025 +0100 net: tn40xx: add pci-id of the aqr105-based Tehuti TN4010 cards [ Upstream commit 53377b5c2952097527b01ce2f1d9a9332f042f70 ] Add the PCI-ID of the AQR105-based Tehuti TN4010 cards to allow loading of the tn40xx driver on these cards. Here, I chose the detailed definition with the subvendor ID similar to the QT2025 cards with the PCI-ID TEHUTI:0x4022, because there is a card with an AQ2104 hiding amongst the AQR105 cards, and they all come with the same PCI-ID (TEHUTI:0x4025). But the AQ2104 is currently not supported. Signed-off-by: Hans-Frieder Vogt Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250322-tn9510-v3a-v7-7-672a9a3d8628@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e542640c2e59e849b76bfef5b8274d57e1264de Author: Daniel Hsu Date: Tue Mar 25 16:10:08 2025 +0800 mctp: Fix incorrect tx flow invalidation condition in mctp-i2c [ Upstream commit 70facbf978ac90c6da17a3de2a8dd111b06f1bac ] Previously, the condition for invalidating the tx flow in mctp_i2c_invalidate_tx_flow() checked if `rc` was nonzero. However, this could incorrectly trigger the invalidation even when `rc > 0` was returned as a success status. This patch updates the condition to explicitly check for `rc < 0`, ensuring that only error cases trigger the invalidation. Signed-off-by: Daniel Hsu Reviewed-by: Jeremy Kerr Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c0d63ee0dd06334c3224c1719b730b2345cc51cd Author: Krzysztof Kozlowski Date: Wed Mar 12 20:24:59 2025 +0100 ASoC: codecs: wsa883x: Correct VI sense channel mask [ Upstream commit ed3b274abc4008efffebf1997968a3f2720a86d3 ] VI sense port on WSA883x speaker takes only one channel, so use 0x1 as channel mask. This fixes garbage being recorded by the speaker when testing the VI sense feedback path. Cc: Srinivas Kandagatla Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250312-asoc-wsa88xx-visense-v1-1-9ca705881122@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 780699001b8e2c167779858cb72f0449cf248278 Author: Krzysztof Kozlowski Date: Wed Mar 12 20:25:00 2025 +0100 ASoC: codecs: wsa884x: Correct VI sense channel mask [ Upstream commit 060fac202eb8e5c83961f0e0bf6dad8ab6e46643 ] VI sense port on WSA883x speaker takes only one channel, so use 0x1 as channel mask. This fixes garbage being recorded by the speaker when testing the VI sense feedback path. Cc: Srinivas Kandagatla Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250312-asoc-wsa88xx-visense-v1-2-9ca705881122@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ace57bd1fb49d193edec5f6a1f255f48dd5fca90 Author: Luis de Arquer Date: Fri Mar 21 13:57:53 2025 +0100 spi-rockchip: Fix register out of bounds access [ Upstream commit 7a874e8b54ea21094f7fd2d428b164394c6cb316 ] Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense. Signed-off-by: Luis de Arquer Link: https://patch.msgid.link/365ccddfba110549202b3520f4401a6a936e82a8.camel@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dac9e6af5328fd1228356cb41d95be4b7d1a968b Author: Trond Myklebust Date: Mon Mar 24 19:05:48 2025 -0400 SUNRPC: rpcbind should never reset the port to the value '0' [ Upstream commit 214c13e380ad7636631279f426387f9c4e3c14d9 ] If we already had a valid port number for the RPC service, then we should not allow the rpcbind client to set it to the invalid value '0'. Reviewed-by: Jeff Layton Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 984d8a392f6b3f254cef7a7edc0a9830c434d7bb Author: Trond Myklebust Date: Mon Mar 24 19:35:01 2025 -0400 SUNRPC: rpc_clnt_set_transport() must not change the autobind setting [ Upstream commit bf9be373b830a3e48117da5d89bb6145a575f880 ] The autobind setting was supposed to be determined in rpc_create(), since commit c2866763b402 ("SUNRPC: use sockaddr + size when creating remote transport endpoints"). Reviewed-by: Jeff Layton Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 71e07bb1556c725b105a275d411373d6191f2150 Author: Trond Myklebust Date: Mon Mar 24 20:35:33 2025 -0400 NFSv4: Treat ENETUNREACH errors as fatal for state recovery [ Upstream commit 0af5fb5ed3d2fd9e110c6112271f022b744a849a ] If a containerised process is killed and causes an ENETUNREACH or ENETDOWN error to be propagated to the state manager, then mark the nfs_client as being dead so that we don't loop in functions that are expecting recovery to succeed. Reviewed-by: Jeff Layton Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 1e317f578116085950469c35d6c9d27ee4ccddb5 Author: Pali Rohár Date: Wed Oct 30 22:46:20 2024 +0100 cifs: Fix establishing NetBIOS session for SMB2+ connection [ Upstream commit 781802aa5a5950f99899f13ff9d760f5db81d36d ] Function ip_rfc1001_connect() which establish NetBIOS session for SMB connections, currently uses smb_send() function for sending NetBIOS Session Request packet. This function expects that the passed buffer is SMB packet and for SMB2+ connections it mangles packet header, which breaks prepared NetBIOS Session Request packet. Result is that this function send garbage packet for SMB2+ connection, which SMB2+ server cannot parse. That function is not mangling packets for SMB1 connections, so it somehow works for SMB1. Fix this problem and instead of smb_send(), use smb_send_kvec() function which does not mangle prepared packet, this function send them as is. Just API of this function takes struct msghdr (kvec) instead of packet buffer. [MS-SMB2] specification allows SMB2 protocol to use NetBIOS as a transport protocol. NetBIOS can be used over TCP via port 139. So this is a valid configuration, just not so common. And even recent Windows versions (e.g. Windows Server 2022) still supports this configuration: SMB over TCP port 139, including for modern SMB2 and SMB3 dialects. This change fixes SMB2 and SMB3 connections over TCP port 139 which requires establishing of NetBIOS session. Tested that this change fixes establishing of SMB2 and SMB3 connections with Windows Server 2022. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 51d44dba94e79dad9c64e4181392b11986934adf Author: Namjae Jeon Date: Wed Feb 12 17:52:19 2025 +0900 cifs: add validation check for the fields in smb_aces [ Upstream commit eeb827f2922eb07ffbf7d53569cc95b38272646f ] cifs.ko is missing validation check when accessing smb_aces. This patch add validation check for the fields in smb_aces. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 15c961d7a9e5f16dd6b7490568e6040d19a46f55 Author: Pali Rohár Date: Sun Oct 27 12:10:52 2024 +0100 cifs: Set default Netbios RFC1001 server name to hostname in UNC [ Upstream commit be786e509c1af9b2dcf25c3d601f05c8c251f482 ] Windows SMB servers (including SMB2+) which are working over RFC1001 require that Netbios server name specified in RFC1001 Session Request packet is same as the UNC host name. Netbios server name can be already specified manually via -o servern= option. With this change the RFC1001 server name is set automatically by extracting the hostname from the mount source. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ff968e486e420c6b5b56efad64685ddab59655ed Author: Zsolt Kajtar Date: Sat Feb 1 09:18:09 2025 +0100 fbdev: core: tileblit: Implement missing margin clearing for tileblit [ Upstream commit 76d3ca89981354e1f85a3e0ad9ac4217d351cc72 ] I was wondering why there's garbage at the bottom of the screen when tile blitting is used with an odd mode like 1080, 600 or 200. Sure there's only space for half a tile but the same area is clean when the buffer is bitmap. Then later I found that it's supposed to be cleaned but that's not implemented. So I took what's in bitblit and adapted it for tileblit. This implementation was tested for both the horizontal and vertical case, and now does the same as what's done for bitmap buffers. If anyone is interested to reproduce the problem then I could bet that'd be on a S3 or Ark. Just set up a mode with an odd line count and make sure that the virtual size covers the complete tile at the bottom. E.g. for 600 lines that's 608 virtual lines for a 16 tall tile. Then the bottom area should be cleaned. For the right side it's more difficult as there the drivers won't let an odd size happen, unless the code is modified. But once it reports back a few pixel columns short then fbcon won't use the last column. With the patch that column is now clean. Btw. the virtual size should be rounded up by the driver for both axes (not only the horizontal) so that it's dividable by the tile size. That's a driver bug but correcting it is not in scope for this patch. Implement missing margin clearing for tileblit Signed-off-by: Zsolt Kajtar Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 8c912c0a6860c3283afcb793a94d483c688e8e99 Author: Zsolt Kajtar Date: Sun Feb 2 21:33:46 2025 +0100 fbcon: Use correct erase colour for clearing in fbcon [ Upstream commit 892c788d73fe4a94337ed092cb998c49fa8ecaf4 ] The erase colour calculation for fbcon clearing should use get_color instead of attr_col_ec, like everything else. The latter is similar but is not correct. For example it's missing the depth dependent remapping and doesn't care about blanking. The problem can be reproduced by setting up the background colour to grey (vt.color=0x70) and having an fbcon console set to 2bpp (4 shades of gray). Now the background attribute should be 1 (dark gray) on the console. If the screen is scrolled when pressing enter in a shell prompt at the bottom line then the new line is cleared using colour 7 instead of 1. That's not something fillrect likes (at 2bbp it expect 0-3) so the result is interesting. This patch switches to get_color with vc_video_erase_char to determine the erase colour from attr_col_ec. That makes the latter function redundant as no other users were left. Use correct erase colour for clearing in fbcon Signed-off-by: Zsolt Kajtar Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 230abe5d3f68b4edca589992ca1b17a7a709cdc6 Author: Shixiong Ou Date: Mon Mar 10 09:54:31 2025 +0800 fbdev: fsl-diu-fb: add missing device_remove_file() [ Upstream commit 86d16cd12efa547ed43d16ba7a782c1251c80ea8 ] Call device_remove_file() when driver remove. Signed-off-by: Shixiong Ou Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 6427b5c0f0aae93577fdcfb647884515cc9d9264 Author: Samuel Holland Date: Sat Oct 26 10:13:54 2024 -0700 riscv: Allow NOMMU kernels to access all of RAM [ Upstream commit 2c0391b29b27f315c1b4c29ffde66f50b29fab99 ] NOMMU kernels currently cannot access memory below the kernel link address. Remove this restriction by setting PAGE_OFFSET to the actual start of RAM, as determined from the devicetree. The kernel link address must be a constant, so keep using CONFIG_PAGE_OFFSET for that purpose. Signed-off-by: Samuel Holland Reviewed-by: Jesse Taube Link: https://lore.kernel.org/r/20241026171441.3047904-3-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 15787ab82a46192ad3d9feff98f804696f873928 Author: Tudor Ambarus Date: Mon Feb 24 08:27:13 2025 +0000 mailbox: use error ret code of of_parse_phandle_with_args() [ Upstream commit 24fdd5074b205cfb0ef4cd0751a2d03031455929 ] In case of error, of_parse_phandle_with_args() returns -EINVAL when the passed index is negative, or -ENOENT when the index is for an empty phandle. The mailbox core overwrote the error return code with a less precise -ENODEV. Use the error returned code from of_parse_phandle_with_args(). Signed-off-by: Tudor Ambarus Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2c80f975e94d548a580932f22f211098f76e315c Author: Sudeep Holla Date: Thu Mar 13 15:28:51 2025 +0000 mailbox: pcc: Use acpi_os_ioremap() instead of ioremap() [ Upstream commit d181acea5b864e91f38f5771b8961215ce5017ae ] The Platform Communication Channel (PCC) mailbox driver currently uses ioremap() to map channel shared memory regions. However it is preferred to use acpi_os_ioremap(), which is mapping function specific to EFI/ACPI defined memory regions. It ensures that the correct memory attributes are applied when mapping ACPI-provided regions. While at it, also add checks for handling any errors with the mapping. Acked-by: Huisong Li Tested-by: Huisong Li Tested-by: Adam Young Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2d21895e77c6446f8cb5005e15c0cc63dad9c14e Author: Jonathan McDowell Date: Fri Mar 7 10:56:44 2025 +0000 tpm: Convert warn to dbg in tpm2_start_auth_session() [ Upstream commit 6359691b4fbcaf3ed86f53043a1f7c6cc54c09be ] TPM2 sessions have been flushed lazily since commit df745e25098dc ("tpm: Lazily flush the auth session"). If /dev/tpm{rm}0 is not accessed in-between two in-kernel calls, it is possible that a TPM2 session is re-started before the previous one has been completed. This causes a spurios warning in a legit run-time condition, which is also correctly addressed with a fast return path: [ 2.944047] tpm tpm0: auth session is active Address the issue by changing dev_warn_once() call to a dev_dbg_once() call. [jarkko: Rewrote the commit message, and instead of dropping converted to a debug message.] Signed-off-by: Jonathan McDowell Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 2eb8f4701961b22ade6a17c417024d2020fa012b Author: Diogo Ivo Date: Mon Mar 17 10:55:07 2025 +0000 ACPI: PNP: Add Intel OC Watchdog IDs to non-PNP device list [ Upstream commit f06777cf2bbc21dd8c71d6e3906934e56b4e18e4 ] Intel Over-Clocking Watchdogs are described in ACPI tables by both the generic PNP0C02 _CID and their ACPI _HID. The presence of the _CID then causes the PNP scan handler to attach to the watchdog, preventing the actual watchdog driver from binding. Address this by adding the ACPI _HIDs to the list of non-PNP devices, so that the PNP scan handler is bypassed. Note that these watchdogs can be described by multiple _HIDs for what seems to be identical hardware. This commit is not a complete list of all the possible watchdog ACPI _HIDs. Signed-off-by: Diogo Ivo Link: https://patch.msgid.link/20250317-ivo-intel_oc_wdt-v3-2-32c396f4eefd@siemens.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4f427ca9edf897302ef20762d6c776840cfb5708 Author: Andy Shevchenko Date: Fri Mar 21 16:40:49 2025 +0200 tracing: Mark binary printing functions with __printf() attribute [ Upstream commit 196a062641fe68d9bfe0ad36b6cd7628c99ad22c ] Binary printing functions are using printf() type of format, and compiler is not happy about them as is: kernel/trace/trace.c:3292:9: error: function ‘trace_vbprintk’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] kernel/trace/trace_seq.c:182:9: error: function ‘trace_seq_bprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] Fix the compilation errors by adding __printf() attribute. While at it, move existing __printf() attributes from the implementations to the declarations. IT also fixes incorrect attribute parameters that are used for trace_array_printk(). Signed-off-by: Andy Shevchenko Reviewed-by: Kees Cook Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20250321144822.324050-4-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit b4c11dd41c40cb2ba877f77c68d6b5db350c65f3 Author: Yi Liu Date: Fri Mar 21 11:01:42 2025 -0700 iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability [ Upstream commit 803f97298e7de9242eb677a1351dcafbbcc9117e ] PASID usage requires PASID support in both device and IOMMU. Since the iommu drivers always enable the PASID capability for the device if it is supported, this extends the IOMMU_GET_HW_INFO to report the PASID capability to userspace. Also, enhances the selftest accordingly. Link: https://patch.msgid.link/r/20250321180143.8468-5-yi.l.liu@intel.com Cc: Bjorn Helgaas Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Zhangfei Gao #aarch64 platform Tested-by: Nicolin Chen Signed-off-by: Yi Liu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e506751b7dd986fd6c48f70c7a98ec7a985b6515 Author: Jinqian Yang Date: Tue Mar 25 22:19:00 2025 +0800 arm64: Add support for HIP09 Spectre-BHB mitigation [ Upstream commit e18c09b204e81702ea63b9f1a81ab003b72e3174 ] The HIP09 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of HIP09 to the list for software mitigation. Signed-off-by: Jinqian Yang Link: https://lore.kernel.org/r/20250325141900.2057314-1-yangjinqian1@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 1a9b696a003ae3d723710b707515a3af17b0904f Author: Trond Myklebust Date: Fri Mar 28 12:52:52 2025 -0400 SUNRPC: Don't allow waiting for exiting tasks [ Upstream commit 14e41b16e8cb677bb440dca2edba8b041646c742 ] Once a task calls exit_signals() it can no longer be signalled. So do not allow it to do killable waits. Reviewed-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ac83bf58f687693c20df74e993921acacd3acdf1 Author: Trond Myklebust Date: Fri Mar 28 13:19:18 2025 -0400 NFS: Don't allow waiting for exiting tasks [ Upstream commit 8d3ca331026a7f9700d3747eed59a67b8f828cdc ] Once a task calls exit_signals() it can no longer be signalled. So do not allow it to do killable waits. Reviewed-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 46a47dc10fa78163bff86d54529c9c9fcbd02e90 Author: Trond Myklebust Date: Thu Mar 27 19:20:53 2025 -0400 NFSv4: Check for delegation validity in nfs_start_delegation_return_locked() [ Upstream commit 9e8f324bd44c1fe026b582b75213de4eccfa1163 ] Check that the delegation is still attached after taking the spin lock in nfs_start_delegation_return_locked(). Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 01677e7ee12f2f6a379f82e35909119f11d554d0 Author: Pavel Begunkov Date: Fri Mar 28 23:11:50 2025 +0000 io_uring/msg: initialise msg request opcode [ Upstream commit 9cc0bbdaba2a66ad90bc6ce45163b7745baffe98 ] It's risky to have msg request opcode set to garbage, so at least initialise it to nop. Later we might want to add a user inaccessible opcode for such cases. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/9afe650fcb348414a4529d89f52eb8969ba06efd.1743190078.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bab0bd138910e234dc2c8d3e9e8e9bfdd5bd7f6a Author: Sungjong Seo Date: Thu Mar 27 00:01:16 2025 +0900 exfat: call bh_read in get_block only when necessary [ Upstream commit c73e680d1f84059e1b1ea82a537f6ccc1c563eb4 ] With commit 11a347fb6cef ("exfat: change to get file size from DataLength"), exfat_get_block() can now handle valid_size. However, most partial unwritten blocks that could be mapped with other blocks are being inefficiently processed separately as individual blocks. Except for partial unwritten blocks that require independent processing, let's handle them simply as before. Signed-off-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d40ca27602eab144a16fa1a1595fb2228eb7b522 Author: Matt Johnston Date: Fri Feb 14 09:17:53 2025 +0800 fuse: Return EPERM rather than ENOSYS from link() [ Upstream commit 8344213571b2ac8caf013cfd3b37bc3467c3a893 ] link() is documented to return EPERM when a filesystem doesn't support the operation, return that instead. Link: https://github.com/libfuse/libfuse/issues/925 Signed-off-by: Matt Johnston Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit c9a508b6bbd2f5da31a0ccde1ed68190fa0bff91 Author: Wang Zhaolong Date: Mon Mar 31 21:33:14 2025 +0800 smb: client: Store original IO parameters and prevent zero IO sizes [ Upstream commit 287906b20035a04a234d1a3c64f760a5678387be ] During mount option processing and negotiation with the server, the original user-specified rsize/wsize values were being modified directly. This makes it impossible to recover these values after a connection reset, leading to potential degraded performance after reconnection. The other problem is that When negotiating read and write sizes, there are cases where the negotiated values might calculate to zero, especially during reconnection when server->max_read or server->max_write might be reset. In general, these values come from the negotiation response. According to MS-SMB2 specification, these values should be at least 65536 bytes. This patch improves IO parameter handling: 1. Adds vol_rsize and vol_wsize fields to store the original user-specified values separately from the negotiated values 2. Uses got_rsize/got_wsize flags to determine if values were user-specified rather than checking for non-zero values, which is more reliable 3. Adds a prevent_zero_iosize() helper function to ensure IO sizes are never negotiated down to zero, which could happen in edge cases like when server->max_read/write is zero The changes make the CIFS client more resilient to unusual server responses and reconnection scenarios, preventing potential failures when IO sizes are calculated to be zero. Signed-off-by: Wang Zhaolong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 150f38eddefc43addbbc92c3db8345beca993a39 Author: Pali Rohár Date: Sat Nov 2 20:06:50 2024 +0100 cifs: Fix negotiate retry functionality [ Upstream commit e94e882a6d69525c07589222cf3a6ff57ad12b5b ] SMB negotiate retry functionality in cifs_negotiate() is currently broken and does not work when doing socket reconnect. Caller of this function, which is cifs_negotiate_protocol() requires that tcpStatus after successful execution of negotiate callback stay in CifsInNegotiate. But if the CIFSSMBNegotiate() called from cifs_negotiate() fails due to connection issues then tcpStatus is changed as so repeated CIFSSMBNegotiate() call does not help. Fix this problem by moving retrying code from negotiate callback (which is either cifs_negotiate() or smb2_negotiate()) to cifs_negotiate_protocol() which is caller of those callbacks. This allows to properly handle and implement correct transistions between tcpStatus states as function cifs_negotiate_protocol() already handles it. With this change, cifs_negotiate_protocol() now handles also -EAGAIN error set by the RFC1002_NEGATIVE_SESSION_RESPONSE processing after reconnecting with NetBIOS session. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0705b6d5bc328d6fa422763b1adc94d38d4cfc55 Author: Pali Rohár Date: Sat Dec 28 21:09:54 2024 +0100 cifs: Fix querying and creating MF symlinks over SMB1 [ Upstream commit 4236ac9fe5b8b42756070d4abfb76fed718e87c2 ] Old SMB1 servers without CAP_NT_SMBS do not support CIFS_open() function and instead SMBLegacyOpen() needs to be used. This logic is already handled in cifs_open_file() function, which is server->ops->open callback function. So for querying and creating MF symlinks use open callback function instead of CIFS_open() function directly. This change fixes querying and creating new MF symlinks on Windows 98. Currently cifs_query_mf_symlink() is not able to detect MF symlink and cifs_create_mf_symlink() is failing with EIO error. Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6ebb9d54eccc8026b386e76eff69364d33373da5 Author: Pali Rohár Date: Mon Dec 9 20:44:23 2024 +0100 cifs: Add fallback for SMB2 CREATE without FILE_READ_ATTRIBUTES [ Upstream commit e255612b5ed9f179abe8196df7c2ba09dd227900 ] Some operations, like WRITE, does not require FILE_READ_ATTRIBUTES access. So when FILE_READ_ATTRIBUTES is not explicitly requested for smb2_open_file() then first try to do SMB2 CREATE with FILE_READ_ATTRIBUTES access (like it was before) and then fallback to SMB2 CREATE without FILE_READ_ATTRIBUTES access (less common case). This change allows to complete WRITE operation to a file when it does not grant FILE_READ_ATTRIBUTES permission and its parent directory does not grant READ_DATA permission (parent directory READ_DATA is implicit grant of child FILE_READ_ATTRIBUTES permission). Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 100b452e0eedabd3b30a2b4df998e207e516864e Author: Anthony Krowiak Date: Tue Mar 11 06:32:57 2025 -0400 s390/vfio-ap: Fix no AP queue sharing allowed message written to kernel log [ Upstream commit d33d729afcc8ad2148d99f9bc499b33fd0c0d73b ] An erroneous message is written to the kernel log when either of the following actions are taken by a user: 1. Assign an adapter or domain to a vfio_ap mediated device via its sysfs assign_adapter or assign_domain attributes that would result in one or more AP queues being assigned that are already assigned to a different mediated device. Sharing of queues between mdevs is not allowed. 2. Reserve an adapter or domain for the host device driver via the AP bus driver's sysfs apmask or aqmask attribute that would result in providing host access to an AP queue that is in use by a vfio_ap mediated device. Reserving a queue for a host driver that is in use by an mdev is not allowed. In both cases, the assignment will return an error; however, a message like the following is written to the kernel log: vfio_ap_mdev e1839397-51a0-4e3c-91e0-c3b9c3d3047d: Userspace may not re-assign queue 00.0028 already assigned to \ e1839397-51a0-4e3c-91e0-c3b9c3d3047d Notice the mdev reporting the error is the same as the mdev identified in the message as the one to which the queue is being assigned. It is perfectly okay to assign a queue to an mdev to which it is already assigned; the assignment is simply ignored by the vfio_ap device driver. This patch logs more descriptive and accurate messages for both 1 and 2 above to the kernel log: Example for 1: vfio_ap_mdev 0fe903a0-a323-44db-9daf-134c68627d61: Userspace may not assign queue 00.0033 to mdev: already assigned to \ 62177883-f1bb-47f0-914d-32a22e3a8804 Example for 2: vfio_ap_mdev 62177883-f1bb-47f0-914d-32a22e3a8804: Can not reserve queue 00.0033 for host driver: in use by mdev Signed-off-by: Anthony Krowiak Link: https://lore.kernel.org/r/20250311103304.1539188-1-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit c42f740a07eea4807e98d2d8febc549c957a7b49 Author: Xin Li (Intel) Date: Tue Apr 1 00:57:27 2025 -0700 x86/fred: Fix system hang during S4 resume with FRED enabled [ Upstream commit e5f1e8af9c9e151ecd665f6d2e36fb25fec3b110 ] Upon a wakeup from S4, the restore kernel starts and initializes the FRED MSRs as needed from its perspective. It then loads a hibernation image, including the image kernel, and attempts to load image pages directly into their original page frames used before hibernation unless those frames are currently in use. Once all pages are moved to their original locations, it jumps to a "trampoline" page in the image kernel. At this point, the image kernel takes control, but the FRED MSRs still contain values set by the restore kernel, which may differ from those set by the image kernel before hibernation. Therefore, the image kernel must ensure the FRED MSRs have the same values as before hibernation. Since these values depend only on the location of the kernel text and data, they can be recomputed from scratch. Reported-by: Xi Pardee Reported-by: Todd Brandt Tested-by: Todd Brandt Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li (Intel) Signed-off-by: Ingo Molnar Reviewed-by: Rafael J. Wysocki Reviewed-by: H. Peter Anvin (Intel) Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250401075728.3626147-1-xin@zytor.com Signed-off-by: Sasha Levin commit 192b02f8c7ba824d65945cb40ae4199bc6cef744 Author: Daniel Gomez Date: Fri Mar 28 14:28:37 2025 +0000 kconfig: merge_config: use an empty file as initfile [ Upstream commit a26fe287eed112b4e21e854f173c8918a6a8596d ] The scripts/kconfig/merge_config.sh script requires an existing $INITFILE (or the $1 argument) as a base file for merging Kconfig fragments. However, an empty $INITFILE can serve as an initial starting point, later referenced by the KCONFIG_ALLCONFIG Makefile variable if -m is not used. This variable can point to any configuration file containing preset config symbols (the merged output) as stated in Documentation/kbuild/kconfig.rst. When -m is used $INITFILE will contain just the merge output requiring the user to run make (i.e. KCONFIG_ALLCONFIG=<$INITFILE> make or make olddefconfig). Instead of failing when `$INITFILE` is missing, create an empty file and use it as the starting point for merges. Signed-off-by: Daniel Gomez Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit dac9d6ad5eaf76a05e5a7367c7d8e7af41e700dd Author: Haoran Jiang Date: Fri Apr 25 17:50:42 2025 +0800 samples/bpf: Fix compilation failure for samples/bpf on LoongArch Fedora [ Upstream commit 548762f05d19c5542db7590bcdfb9be1fb928376 ] When building the latest samples/bpf on LoongArch Fedora make M=samples/bpf There are compilation errors as follows: In file included from ./linux/samples/bpf/sockex2_kern.c:2: In file included from ./include/uapi/linux/in.h:25: In file included from ./include/linux/socket.h:8: In file included from ./include/linux/uio.h:9: In file included from ./include/linux/thread_info.h:60: In file included from ./arch/loongarch/include/asm/thread_info.h:15: In file included from ./arch/loongarch/include/asm/processor.h:13: In file included from ./arch/loongarch/include/asm/cpu-info.h:11: ./arch/loongarch/include/asm/loongarch.h:13:10: fatal error: 'larchintrin.h' file not found ^~~~~~~~~~~~~~~ 1 error generated. larchintrin.h is included in /usr/lib64/clang/14.0.6/include, and the header file location is specified at compile time. Test on LoongArch Fedora: https://github.com/fedora-remix-loongarch/releases-info Signed-off-by: Haoran Jiang Signed-off-by: zhangxi Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250425095042.838824-1-jianghaoran@kylinos.cn Signed-off-by: Sasha Levin commit 8014d3e56ec0c662a1bc059b3e6b46b6103879d4 Author: Brandon Kammerdiener Date: Thu Apr 24 11:32:51 2025 -0400 bpf: fix possible endless loop in BPF map iteration [ Upstream commit 75673fda0c557ae26078177dd14d4857afbf128d ] The _safe variant used here gets the next element before running the callback, avoiding the endless loop condition. Signed-off-by: Brandon Kammerdiener Link: https://lore.kernel.org/r/20250424153246.141677-2-brandon.kammerdiener@intel.com Signed-off-by: Alexei Starovoitov Acked-by: Hou Tao Signed-off-by: Sasha Levin commit 218c838d0356a4305a5705fa4599b682d6312144 Author: Pavel Begunkov Date: Thu Apr 24 12:28:39 2025 +0100 io_uring: don't duplicate flushing in io_req_post_cqe [ Upstream commit 5e16f1a68d28965c12b6fa227a306fef8a680f84 ] io_req_post_cqe() sets submit_state.cq_flush so that *flush_completions() can take care of batch commiting CQEs. Don't commit it twice by using __io_cq_unlock_post(). Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/41c416660c509cee676b6cad96081274bcb459f3.1745493861.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 64f505b08e0cfd8163491c8c082d4f47a88e51d4 Author: Darrick J. Wong Date: Wed Apr 23 12:53:42 2025 -0700 block: fix race between set_blocksize and read paths [ Upstream commit c0e473a0d226479e8e925d5ba93f751d8df628e9 ] With the new large sector size support, it's now the case that set_blocksize can change i_blksize and the folio order in a manner that conflicts with a concurrent reader and causes a kernel crash. Specifically, let's say that udev-worker calls libblkid to detect the labels on a block device. The read call can create an order-0 folio to read the first 4096 bytes from the disk. But then udev is preempted. Next, someone tries to mount an 8k-sectorsize filesystem from the same block device. The filesystem calls set_blksize, which sets i_blksize to 8192 and the minimum folio order to 1. Now udev resumes, still holding the order-0 folio it allocated. It then tries to schedule a read bio and do_mpage_readahead tries to create bufferheads for the folio. Unfortunately, blocks_per_folio == 0 because the page size is 4096 but the blocksize is 8192 so no bufferheads are attached and the bh walk never sets bdev. We then submit the bio with a NULL block device and crash. Therefore, truncate the page cache after flushing but before updating i_blksize. However, that's not enough -- we also need to lock out file IO and page faults during the update. Take both the i_rwsem and the invalidate_lock in exclusive mode for invalidations, and in shared mode for read/write operations. I don't know if this is the correct fix, but xfs/259 found it. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Tested-by: Shin'ichiro Kawasaki Link: https://lore.kernel.org/r/174543795699.4139148.2086129139322431423.stgit@frogsfrogsfrogs Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e9f646f089bc37c350da6cbc78e61abfa0fa5673 Author: Ihor Solodrai Date: Wed Apr 16 10:02:46 2025 -0700 selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete failure [ Upstream commit f2858f308131a09e33afb766cd70119b5b900569 ] "sockmap_ktls disconnect_after_delete" test has been failing on BPF CI after recent merges from netdev: * https://github.com/kernel-patches/bpf/actions/runs/14458537639 * https://github.com/kernel-patches/bpf/actions/runs/14457178732 It happens because disconnect has been disabled for TLS [1], and it renders the test case invalid. Removing all the test code creates a conflict between bpf and bpf-next, so for now only remove the offending assert [2]. The test will be removed later on bpf-next. [1] https://lore.kernel.org/netdev/20250404180334.3224206-1-kuba@kernel.org/ [2] https://lore.kernel.org/bpf/cfc371285323e1a3f3b006bfcf74e6cf7ad65258@linux.dev/ Signed-off-by: Ihor Solodrai Signed-off-by: Andrii Nakryiko Reviewed-by: Jiayuan Chen Link: https://lore.kernel.org/bpf/20250416170246.2438524-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cd39fae34f0949104045fdeac522829491c6d6b0 Author: Felix Kuehling Date: Wed Apr 16 00:19:13 2025 -0400 drm/amdgpu: Allow P2P access through XGMI [ Upstream commit a92741e72f91b904c1d8c3d409ed8dbe9c1f2b26 ] If peer memory is accessible through XGMI, allow leaving it in VRAM rather than forcing its migration to GTT on DMABuf attachment. Signed-off-by: Felix Kuehling Tested-by: Hao (Claire) Zhou Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 372c8d72c3680fdea3fbb2d6b089f76b4a6d596a) Signed-off-by: Sasha Levin commit 36cb568f559addbace05ea97f3a5dc076945e97e Author: Nicholas Susanto Date: Wed Apr 2 15:04:08 2025 -0400 drm/amd/display: Enable urgent latency adjustment on DCN35 [ Upstream commit 756c85e4d0ddc497b4ad5b1f41ad54e838e06188 ] [Why] Urgent latency adjustment was disabled on DCN35 due to issues with P0 enablement on some platforms. Without urgent latency, underflows occur when doing certain high timing configurations. After testing, we found that reenabling urgent latency didn't reintroduce p0 support on multiple platforms. [How] renable urgent latency on DCN35 and setting it to 3000 Mhz. This reverts commit 3412860cc4c0c484f53f91b371483e6e4440c3e5. Reviewed-by: Charlene Liu Signed-off-by: Nicholas Susanto Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher (cherry picked from commit cd74ce1f0cddffb3f36d0995d0f61e89f0010738) Signed-off-by: Sasha Levin commit 9ece099e951a56f4de07a3a45d7cedf739abe598 Author: Davidlohr Bueso Date: Thu Apr 17 18:59:20 2025 -0700 fs/ext4: use sleeping version of sb_find_get_block() [ Upstream commit 6e8f57fd09c9fb569d10b2ccc3878155b702591a ] Enable ext4_free_blocks() to use it, which has a cond_resched to begin with. Convert to the new nonatomic flavor to benefit from potential performance benefits and adapt in the future vs migration such that semantics are kept. Suggested-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: Davidlohr Bueso Link: https://kdevops.org/ext4/v6.15-rc2.html # [0] Link: https://lore.kernel.org/all/aAAEvcrmREWa1SKF@bombadil.infradead.org/ # [1] Link: https://lore.kernel.org/20250418015921.132400-7-dave@stgolabs.net Tested-by: kdevops@lists.linux.dev Reviewed-by: Luis Chamberlain Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f1c5aa614b5c251f93a6a4c8c26001d5e9e53fd6 Author: Davidlohr Bueso Date: Thu Apr 17 18:59:19 2025 -0700 fs/jbd2: use sleeping version of __find_get_block() [ Upstream commit f76d4c28a46a9260d85e00dafc8f46d369365d33 ] Convert to the new nonatomic flavor to benefit from potential performance benefits and adapt in the future vs migration such that semantics are kept. - jbd2_journal_revoke(): can sleep (has might_sleep() in the beginning) - jbd2_journal_cancel_revoke(): only used from do_get_write_access() and do_get_create_access() which do sleep. So can sleep. - jbd2_clear_buffer_revoked_flags() - only called from journal commit code which sleeps. So can sleep. Suggested-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: Davidlohr Bueso Link: https://kdevops.org/ext4/v6.15-rc2.html # [0] Link: https://lore.kernel.org/all/aAAEvcrmREWa1SKF@bombadil.infradead.org/ # [1] Link: https://lore.kernel.org/20250418015921.132400-6-dave@stgolabs.net Tested-by: kdevops@lists.linux.dev Reviewed-by: Luis Chamberlain Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit aafc270531431c7851b003300ddf4ee21f9f49be Author: Davidlohr Bueso Date: Thu Apr 17 18:59:18 2025 -0700 fs/ocfs2: use sleeping version of __find_get_block() [ Upstream commit a0b5ff07491010789fcb012bc8f9dad9d26f9a8b ] This is a path that allows for blocking as it does IO. Convert to the new nonatomic flavor to benefit from potential performance benefits and adapt in the future vs migration such that semantics are kept. Suggested-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: Davidlohr Bueso Link: https://kdevops.org/ext4/v6.15-rc2.html # [0] Link: https://lore.kernel.org/all/aAAEvcrmREWa1SKF@bombadil.infradead.org/ # [1] Link: https://lore.kernel.org/20250418015921.132400-5-dave@stgolabs.net Tested-by: kdevops@lists.linux.dev Reviewed-by: Luis Chamberlain Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit a49a4a87cea36bf28de262338f7e9edf36cf944f Author: Davidlohr Bueso Date: Thu Apr 17 18:59:17 2025 -0700 fs/buffer: use sleeping version of __find_get_block() [ Upstream commit 5b67d43976828dea2394eae2556b369bb7a61f64 ] Convert to the new nonatomic flavor to benefit from potential performance benefits and adapt in the future vs migration such that semantics are kept. Convert write_boundary_block() which already takes the buffer lock as well as bdev_getblk() depending on the respective gpf flags. There are no changes in semantics. Suggested-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: Davidlohr Bueso Link: https://kdevops.org/ext4/v6.15-rc2.html # [0] Link: https://lore.kernel.org/all/aAAEvcrmREWa1SKF@bombadil.infradead.org/ # [1] Link: https://lore.kernel.org/20250418015921.132400-4-dave@stgolabs.net Tested-by: kdevops@lists.linux.dev # [0] [1] Reviewed-by: Luis Chamberlain Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e138fc2316c321271fd990e3f3bdd550fac37f9b Author: Davidlohr Bueso Date: Thu Apr 17 18:59:16 2025 -0700 fs/buffer: introduce sleeping flavors for pagecache lookups [ Upstream commit 2814a7d3d2ff5d2cdd22936f641f758fdb971fa0 ] Add __find_get_block_nonatomic() and sb_find_get_block_nonatomic() calls for which users will be converted where safe. These versions will take the folio lock instead of the mapping's private_lock. Reviewed-by: Jan Kara Signed-off-by: Davidlohr Bueso Link: https://kdevops.org/ext4/v6.15-rc2.html # [0] Link: https://lore.kernel.org/all/aAAEvcrmREWa1SKF@bombadil.infradead.org/ # [1] Link: https://lore.kernel.org/20250418015921.132400-3-dave@stgolabs.net Tested-by: kdevops@lists.linux.dev Reviewed-by: Luis Chamberlain Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 4f5553a08fb74745f6ae6034adf251a2d4219de5 Author: Davidlohr Bueso Date: Thu Apr 17 18:59:15 2025 -0700 fs/buffer: split locking for pagecache lookups [ Upstream commit 7ffe3de53a885dbb5836541c2178bd07d1bad7df ] Callers of __find_get_block() may or may not allow for blocking semantics, and is currently assumed that it will not. Layout two paths based on this. The the private_lock scheme will continued to be used for atomic contexts. Otherwise take the folio lock instead, which protects the buffers, such as vs migration and try_to_free_buffers(). Per the "hack idea", the latter can alleviate contention on the private_lock for bdev mappings. For reasons of determinism and avoid making bugs hard to reproduce, the trylocking is not attempted. No change in semantics. All lookup users still take the spinlock. Reviewed-by: Jan Kara Signed-off-by: Davidlohr Bueso Link: https://kdevops.org/ext4/v6.15-rc2.html # [0] Link: https://lore.kernel.org/all/aAAEvcrmREWa1SKF@bombadil.infradead.org/ # [1] Link: https://lore.kernel.org/20250418015921.132400-2-dave@stgolabs.net Tested-by: kdevops@lists.linux.dev Reviewed-by: Luis Chamberlain Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 836917e7a65cd47d2d7cc2d46305573a155ffd5d Author: Frederick Lawler Date: Thu Mar 27 11:09:11 2025 -0500 ima: process_measurement() needlessly takes inode_lock() on MAY_READ [ Upstream commit 30d68cb0c37ebe2dc63aa1d46a28b9163e61caa2 ] On IMA policy update, if a measure rule exists in the policy, IMA_MEASURE is set for ima_policy_flags which makes the violation_check variable always true. Coupled with a no-action on MAY_READ for a FILE_CHECK call, we're always taking the inode_lock(). This becomes a performance problem for extremely heavy read-only workloads. Therefore, prevent this only in the case there's no action to be taken. Signed-off-by: Frederick Lawler Acked-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit e22034cbee52b6c42e81960a09c6b2cef41187ed Author: Balbir Singh Date: Tue Apr 22 21:40:34 2025 +1000 dma-mapping: Fix warning reported for missing prototype [ Upstream commit cae5572ec9261f752af834cdaaf5a0ba0afcf256 ] lkp reported a warning about missing prototype for a recent patch. The kernel-doc style comments are out of sync, move them to the right function. Cc: Marek Szyprowski Cc: Christoph Hellwig Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202504190615.g9fANxHw-lkp@intel.com/ Signed-off-by: Balbir Singh [mszyprow: reformatted subject] Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20250422114034.3535515-1-balbirs@nvidia.com Signed-off-by: Sasha Levin commit 7f7f70c31697654d8c9c3189ba8b8f540f7a5a46 Author: Vladimir Oltean Date: Thu Apr 17 15:00:04 2025 +0300 net: enetc: refactor bulk flipping of RX buffers to separate function [ Upstream commit 1d587faa5be7e9785b682cc5f58ba8f4100c13ea ] This small snippet of code ensures that we do something with the array of RX software buffer descriptor elements after passing the skb to the stack. In this case, we see if the other half of the page is reusable, and if so, we "turn around" the buffers, making them directly usable by enetc_refill_rx_ring() without going to enetc_new_page(). We will need to perform this kind of buffer flipping from a new code path, i.e. from XDP_PASS. Currently, enetc_build_skb() does it there buffer by buffer, but in a subsequent change we will stop using enetc_build_skb() for XDP_PASS. Signed-off-by: Vladimir Oltean Reviewed-by: Wei Fang Link: https://patch.msgid.link/20250417120005.3288549-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 523c08f630a3d436ff5143df80e66dcafb14f4cf Author: Ranjan Kumar Date: Tue Apr 15 15:45:46 2025 +0530 scsi: mpi3mr: Add level check to control event logging [ Upstream commit b0b7ee3b574a72283399b9232f6190be07f220c0 ] Ensure event logs are only generated when the debug logging level MPI3_DEBUG_EVENT is enabled. This prevents unnecessary logging. Signed-off-by: Ranjan Kumar Link: https://lore.kernel.org/r/20250415101546.204018-1-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bd8c9404e44adb9f6219c09b3409a61ab7ce3427 Author: Dongli Zhang Date: Wed Apr 2 23:29:46 2025 -0700 vhost-scsi: protect vq->log_used with vq->mutex [ Upstream commit f591cf9fce724e5075cc67488c43c6e39e8cbe27 ] The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue. Signed-off-by: Dongli Zhang Acked-by: Jason Wang Reviewed-by: Mike Christie Message-Id: <20250403063028.16045-2-dongli.zhang@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit f93675793bdcddbae139cb409d91f26037664283 Author: Stefano Garzarella Date: Thu Mar 27 13:44:35 2025 +0100 vhost_task: fix vhost_task_create() documentation [ Upstream commit fec0abf52609c20279243699d08b660c142ce0aa ] Commit cb380909ae3b ("vhost: return task creation error instead of NULL") changed the return value of vhost_task_create(), but did not update the documentation. Reflect the change in the documentation: on an error, vhost_task_create() returns an ERR_PTR() and no longer NULL. Signed-off-by: Stefano Garzarella Message-Id: <20250327124435.142831-1-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 97edaa0ec64c5354e7dd794560201b1c98761d9c Author: gaoxu Date: Thu Apr 17 07:30:00 2025 +0000 cgroup: Fix compilation issue due to cgroup_mutex not being exported [ Upstream commit 87c259a7a359e73e6c52c68fcbec79988999b4e6 ] When adding folio_memcg function call in the zram module for Android16-6.12, the following error occurs during compilation: ERROR: modpost: "cgroup_mutex" [../soc-repo/zram.ko] undefined! This error is caused by the indirect call to lockdep_is_held(&cgroup_mutex) within folio_memcg. The export setting for cgroup_mutex is controlled by the CONFIG_PROVE_RCU macro. If CONFIG_LOCKDEP is enabled while CONFIG_PROVE_RCU is not, this compilation error will occur. To resolve this issue, add a parallel macro CONFIG_LOCKDEP control to ensure cgroup_mutex is properly exported when needed. Signed-off-by: gao xu Acked-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 3eec42a17ad4d09dde8e981076e8cbc17073d35b Author: Marek Szyprowski Date: Tue Apr 15 09:56:59 2025 +0200 dma-mapping: avoid potential unused data compilation warning [ Upstream commit c9b19ea63036fc537a69265acea1b18dabd1cbd3 ] When CONFIG_NEED_DMA_MAP_STATE is not defined, dma-mapping clients might report unused data compilation warnings for dma_unmap_*() calls arguments. Redefine macros for those calls to let compiler to notice that it is okay when the provided arguments are not used. Reported-by: Andy Shevchenko Suggested-by: Jakub Kicinski Signed-off-by: Marek Szyprowski Tested-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250415075659.428549-1-m.szyprowski@samsung.com Signed-off-by: Sasha Levin commit a8dd6b7b391d9b33ea42b06b0621381ae9e320d3 Author: Hans de Goede Date: Tue Mar 18 15:12:03 2025 +0100 mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type [ Upstream commit f88c0c72ffb014e5eba676ee337c4eb3b1d6a119 ] vsc_tp.tx_buf and vsc_tp.rx_buf point to a struct vsc_tp_packet, use the correct type instead of "void *" and use sizeof(*ptr) when allocating memory for these buffers. Signed-off-by: Hans de Goede Reviewed-by: Alexander Usyskin Reviewed-by: Sakari Ailus Link: https://lore.kernel.org/r/20250318141203.94342-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit de8c0b93a63cf8eb3dbd234617cdc1daef951843 Author: Lorenzo Stoakes Date: Mon Mar 31 13:56:08 2025 +0100 intel_th: avoid using deprecated page->mapping, index fields [ Upstream commit 8e553520596bbd5ce832e26e9d721e6a0c797b8b ] The struct page->mapping, index fields are deprecated and soon to be only available as part of a folio. It is likely the intel_th code which sets page->mapping, index is was implemented out of concern that some aspect of the page fault logic may encounter unexpected problems should they not. However, the appropriate interface for inserting kernel-allocated memory is vm_insert_page() in a VM_MIXEDMAP. By using the helper function vmf_insert_mixed() we can do this with minimal churn in the existing fault handler. By doing so, we bypass the remainder of the faulting logic. The pages are still pinned so there is no possibility of anything unexpected being done with the pages once established. It would also be reasonable to pre-map everything on fault, however to minimise churn we retain the fault handler. We also eliminate all code which clears page->mapping on teardown as this has now become unnecessary. The MSU code relies on faulting to function correctly, so is by definition dependent on CONFIG_MMU. We avoid spurious reports about compilation failure for unsupported platforms by making this requirement explicit in Kconfig as part of this change too. Signed-off-by: Lorenzo Stoakes Acked-by: Alexander Shishkin Link: https://lore.kernel.org/r/20250331125608.60300-1-lorenzo.stoakes@oracle.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 299881317756d8c6831e373e422b3be2b671362e Author: Balbir Singh Date: Mon Apr 14 21:37:52 2025 +1000 dma/mapping.c: dev_dbg support for dma_addressing_limited [ Upstream commit 2042c352e21d19eaf5f9e22fb6afce72293ef28c ] In the debug and resolution of an issue involving forced use of bounce buffers, 7170130e4c72 ("x86/mm/init: Handle the special case of device private pages in add_pages(), to not increase max_pfn and trigger dma_addressing_limited() bounce buffers"). It would have been easier to debug the issue if dma_addressing_limited() had debug information about the device not being able to address all of memory and thus forcing all accesses through a bounce buffer. Please see[2] Implement dev_dbg to debug the potential use of bounce buffers when we hit the condition. When swiotlb is used, dma_addressing_limited() is used to determine the size of maximum dma buffer size in dma_direct_max_mapping_size(). The debug prints could be triggered in that check as well (when enabled). Link: https://lore.kernel.org/lkml/20250401000752.249348-1-balbirs@nvidia.com/ [1] Link: https://lore.kernel.org/lkml/20250310112206.4168-1-spasswolf@web.de/ [2] Cc: Marek Szyprowski Cc: Robin Murphy Cc: "Christian König" Cc: Ingo Molnar Cc: Kees Cook Cc: Bjorn Helgaas Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Andy Lutomirski Cc: Alex Deucher Cc: Bert Karwatzki Cc: Christoph Hellwig Signed-off-by: Balbir Singh Reviewed-by: Christoph Hellwig Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20250414113752.3298276-1-balbirs@nvidia.com Signed-off-by: Sasha Levin commit b730cb109633c455ce8a7cd6934986c6a16d88d8 Author: Zhongqiu Han Date: Wed Mar 12 21:04:12 2025 +0800 virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN [ Upstream commit 2e2f925fe737576df2373931c95e1a2b66efdfef ] syzbot reports a data-race when accessing the event_triggered, here is the simplified stack when the issue occurred: ================================================================== BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline] read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline] value changed: 0x01 -> 0x00 ================================================================== When the data race occurs, the function virtqueue_enable_cb_delayed() sets event_triggered to false, and virtqueue_disable_cb_split/packed() reads it as false due to the race condition. Since event_triggered is an unreliable hint used for optimization, this should only cause the driver temporarily suggest that the device not send an interrupt notification when the event index is used. Fix this KCSAN reported data-race issue by explicitly tagging the access as data_racy. Reported-by: syzbot+efe683d57990864b8c8e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67c7761a.050a0220.15b4b9.0018.GAE@google.com/ Signed-off-by: Zhongqiu Han Message-Id: <20250312130412.3516307-1-quic_zhonhan@quicinc.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 7aea1517fb6c978e32124a479a14249ca6c0b4c2 Author: Manish Pandey Date: Fri Apr 11 17:46:30 2025 +0530 scsi: ufs: Introduce quirk to extend PA_HIBERN8TIME for UFS devices [ Upstream commit 569330a34a31a52c904239439984a59972c11d28 ] Samsung UFS devices require additional time in hibern8 mode before exiting, beyond the negotiated handshaking phase between the host and device. Introduce a quirk to increase the PA_HIBERN8TIME parameter by 100 µs, a value derived from experiments, to ensure a proper hibernation process. Signed-off-by: Manish Pandey Link: https://lore.kernel.org/r/20250411121630.21330-3-quic_mapa@quicinc.com Reviewed-by: Bean Huo Reviewed-by: Manivannan Sadhasivam Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 87389bff743c55b6b85282de91109391f43e0814 Author: Dmitry Bogdanov Date: Tue Dec 24 13:17:57 2024 +0300 scsi: target: iscsi: Fix timeout on deleted connection [ Upstream commit 7f533cc5ee4c4436cee51dc58e81dfd9c3384418 ] NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started. Signed-off-by: Dmitry Bogdanov Link: https://lore.kernel.org/r/20241224101757.32300-1-d.bogdanov@yadro.com Reviewed-by: Maurizio Lombardi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1603a34b80ffb7c52acce5d80cf7465eb56104c8 Author: Dmitry Baryshkov Date: Fri Apr 11 12:22:49 2025 +0100 nvmem: qfprom: switch to 4-byte aligned reads [ Upstream commit 3566a737db87a9bf360c2fd36433c5149f805f2e ] All platforms since Snapdragon 8 Gen1 (SM8450) require using 4-byte reads to access QFPROM data. While older platforms were more than happy with 1-byte reads, change the qfprom driver to use 4-byte reads for all the platforms. Specify stride and word size of 4 bytes. To retain compatibility with the existing DT and to simplify porting data from vendor kernels, use fixup_dt_cell_info in order to bump alignment requirements. Signed-off-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250411112251.68002-12-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 410f8b72e02c64c4bd6e8566663c77e7aeb8bc45 Author: Dmitry Baryshkov Date: Fri Apr 11 12:22:48 2025 +0100 nvmem: core: update raw_len if the bit reading is required [ Upstream commit 6786484223d5705bf7f919c1e5055d478ebeec32 ] If NVMEM cell uses bit offset or specifies bit truncation, update raw_len manually (following the cell->bytes update), ensuring that the NVMEM access is still word-aligned. Signed-off-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250411112251.68002-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4327479e559c05fd31483a58e4df1f0c6c3fbd64 Author: Dmitry Baryshkov Date: Fri Apr 11 12:22:47 2025 +0100 nvmem: core: verify cell's raw_len [ Upstream commit 13bcd440f2ff38cd7e42a179c223d4b833158b33 ] Check that the NVMEM cell's raw_len is a aligned to word_size. Otherwise Otherwise drivers might face incomplete read while accessing the last part of the NVMEM cell. Signed-off-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250411112251.68002-10-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a4f865ecdbdd2b466f7914c293246c3c13654fc4 Author: Dmitry Baryshkov Date: Fri Apr 11 12:22:46 2025 +0100 nvmem: core: fix bit offsets of more than one byte [ Upstream commit 7a06ef75107799675ea6e4d73b9df37e18e352a8 ] If the NVMEM specifies a stride to access data, reading particular cell might require bit offset that is bigger than one byte. Rework NVMEM core code to support bit offsets of more than 8 bits. Signed-off-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250411112251.68002-9-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d6abe0f6ade98dbc410855d75cbc21fe345b80a9 Author: Heiko Stuebner Date: Fri Apr 11 12:22:42 2025 +0100 nvmem: rockchip-otp: add rk3576 variant data [ Upstream commit 50d75a13a9ce880a5ef07a4ccc63ba561cc2e69a ] The variant works very similar to the rk3588, just with a different read-offset and size. Signed-off-by: Heiko Stuebner Tested-by: Nicolas Frattaroli Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250411112251.68002-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 49b4e88b559cdc03283b093db600bdad36ddccea Author: Heiko Stuebner Date: Fri Apr 11 12:22:39 2025 +0100 nvmem: rockchip-otp: Move read-offset into variant-data [ Upstream commit 6907e8093b3070d877ee607e5ceede60cfd08bde ] The RK3588 has an offset into the OTP area where the readable area begins and automatically adds this to the start address. Other variants are very much similar to rk3588, just with a different offset, so move that value into variant-data. To match the size in bytes, store this value also in bytes and not in number of blocks. Signed-off-by: Heiko Stuebner Tested-by: Nicolas Frattaroli Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250411112251.68002-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3fc60952271b601ceee34dcf6f72c1de660172e1 Author: Pengyu Luo Date: Sat Apr 5 00:42:19 2025 +0800 cpufreq: Add SM8650 to cpufreq-dt-platdev blocklist [ Upstream commit fc5414a4774e14e51a93499a6adfdc45f2de82e0 ] SM8650 have already been supported by qcom-cpufreq-hw driver, but never been added to cpufreq-dt-platdev. This makes noise [ 0.388525] cpufreq-dt cpufreq-dt: failed register driver: -17 [ 0.388537] cpufreq-dt cpufreq-dt: probe with driver cpufreq-dt failed with error -17 So adding it to the cpufreq-dt-platdev driver's blocklist to fix it. Signed-off-by: Pengyu Luo Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit c000fc26c431e40a4e5e6d7a9e42ef0aa06331cf Author: Claudiu Beznea Date: Wed May 7 15:50:31 2025 +0300 phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off [ Upstream commit 9ce71e85b29eb63e48e294479742e670513f03a0 ] Assert PLL reset on PHY power off. This saves power. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Reviewed-by: Lad Prabhakar Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250507125032.565017-5-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 918d43686271ed94af6d67706ee7775d952a04e0 Author: Claudiu Beznea Date: Wed May 7 15:50:30 2025 +0300 phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data [ Upstream commit 55a387ebb9219cbe4edfa8ba9996ccb0e7ad4932 ] The phy-rcar-gen3-usb2 driver exposes four individual PHYs that are requested and configured by PHY users. The struct phy_ops APIs access the same set of registers to configure all PHYs. Additionally, PHY settings can be modified through sysfs or an IRQ handler. While some struct phy_ops APIs are protected by a driver-wide mutex, others rely on individual PHY-specific mutexes. This approach can lead to various issues, including: 1/ the IRQ handler may interrupt PHY settings in progress, racing with hardware configuration protected by a mutex lock 2/ due to msleep(20) in rcar_gen3_init_otg(), while a configuration thread suspends to wait for the delay, another thread may try to configure another PHY (with phy_init() + phy_power_on()); re-running the phy_init() goes to the exact same configuration code, re-running the same hardware configuration on the same set of registers (and bits) which might impact the result of the msleep for the 1st configuring thread 3/ sysfs can configure the hardware (though role_store()) and it can still race with the phy_init()/phy_power_on() APIs calling into the drivers struct phy_ops To address these issues, add a spinlock to protect hardware register access and driver private data structures (e.g., calls to rcar_gen3_is_any_rphy_initialized()). Checking driver-specific data remains necessary as all PHY instances share common settings. With this change, the existing mutex protection is removed and the cleanup.h helpers are used. While at it, to keep the code simpler, do not skip regulator_enable()/regulator_disable() APIs in rcar_gen3_phy_usb2_power_on()/rcar_gen3_phy_usb2_power_off() as the regulators enable/disable operations are reference counted anyway. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Reviewed-by: Lad Prabhakar Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250507125032.565017-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Stable-dep-of: 9ce71e85b29e ("phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off") Signed-off-by: Sasha Levin commit 64cf5b896fd39212f33715839f6d62e420c74548 Author: Claudiu Beznea Date: Wed May 7 15:50:29 2025 +0300 phy: renesas: rcar-gen3-usb2: Move IRQ request in probe [ Upstream commit de76809f60cc938d3580bbbd5b04b7d12af6ce3a ] Commit 08b0ad375ca6 ("phy: renesas: rcar-gen3-usb2: move IRQ registration to init") moved the IRQ request operation from probe to struct phy_ops::phy_init API to avoid triggering interrupts (which lead to register accesses) while the PHY clocks (enabled through runtime PM APIs) are not active. If this happens, it results in a synchronous abort. One way to reproduce this issue is by enabling CONFIG_DEBUG_SHIRQ, which calls free_irq() on driver removal. Move the IRQ request and free operations back to probe, and take the runtime PM state into account in IRQ handler. This commit is preparatory for the subsequent fixes in this series. Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Reviewed-by: Lad Prabhakar Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250507125032.565017-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Stable-dep-of: 9ce71e85b29e ("phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off") Signed-off-by: Sasha Levin commit 0abae7dc42f2189a97a1f751e2a44d7b8e5d588d Author: Christophe JAILLET Date: Tue May 13 19:56:41 2025 +0200 i2c: designware: Fix an error handling path in i2c_dw_pci_probe() [ Upstream commit 1cfe51ef07ca3286581d612debfb0430eeccbb65 ] If navi_amd_register_client() fails, the previous i2c_dw_probe() call should be undone by a corresponding i2c_del_adapter() call, as already done in the remove function. Fixes: 17631e8ca2d3 ("i2c: designware: Add driver support for AMD NAVI GPU") Signed-off-by: Christophe JAILLET Cc: # v5.13+ Acked-by: Jarkko Nikula Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/fcd9651835a32979df8802b2db9504c523a8ebbb.1747158983.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 0d1002c60cd47fe84cfed9d5724286c114520fb6 Author: Andy Shevchenko Date: Wed Sep 25 15:44:19 2024 +0300 i2c: designware: Use temporary variable for struct device [ Upstream commit d2f94dccab8319063dd1fbc1738b4a280c2e4009 ] Use temporary variable for struct device to make code neater. Reviewed-by: Mario Limonciello Reviewed-by: Andi Shyti Signed-off-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Andi Shyti Stable-dep-of: 1cfe51ef07ca ("i2c: designware: Fix an error handling path in i2c_dw_pci_probe()") Signed-off-by: Sasha Levin commit 4fa55c5230f4c93e385c5a078486ac8a67b2adf2 Author: John Olender Date: Wed Apr 16 02:54:26 2025 -0400 drm/amd/display: Defer BW-optimization-blocked DRR adjustments [ Upstream commit 874697e127931bf50a37ce9d96ee80f3a08a0c38 ] [Why & How] Instead of dropping DRR updates, defer them. This fixes issues where monitor continues to see incorrect refresh rate after VRR was turned off by userspace. Fixes: 32953485c558 ("drm/amd/display: Do not update DRR while BW optimizations pending") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3546 Reviewed-by: Sun peng Li Signed-off-by: John Olender Signed-off-by: Aurabindo Pillai Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 53761b7ecd83e6fbb9f2206f8c980a6aa308c844) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5f05863810cfd6df3704d91ad6d6e32a39be3211 Author: Zhongwei Zhang Date: Fri Feb 28 10:35:23 2025 +0800 drm/amd/display: Correct timing_adjust_pending flag setting. [ Upstream commit 34935701b7ed1a1ef449310ba041f10964b23cf4 ] [Why&How] stream->adjust will be overwritten by update->crtc_timing_adjust. We should set update->crtc_timing_adjust->timing_adjust_pending and then overwrite stream->adjust. Reset update->crtc_timing_adjust->timing_adjust_pending after the assignment. Reviewed-by: Charlene Liu Signed-off-by: Zhongwei Zhang Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 874697e12793 ("drm/amd/display: Defer BW-optimization-blocked DRR adjustments") Signed-off-by: Sasha Levin commit 839b2350b861faa8a791f5330e366624512213d7 Author: Danny Wang Date: Thu Feb 13 16:18:34 2025 +0800 drm/amd/display: Do not enable replay when vtotal update is pending. [ Upstream commit bd00b29b5f236dce677089319176dee5872b5a7a ] [Why&How] Vtotal is not applied to HW when handling vsync interrupt. Make sure vtotal is aligned before enable replay. Reviewed-by: Anthony Koo Reviewed-by: Robin Chen Signed-off-by: Danny Wang Signed-off-by: Zhongwei Zhang Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 874697e12793 ("drm/amd/display: Defer BW-optimization-blocked DRR adjustments") Signed-off-by: Sasha Levin commit 892f054b3fa2a3ee233cd64384f1847029273e48 Author: Dillon Varone Date: Fri Sep 20 16:56:20 2024 -0400 drm/amd/display: Configure DTBCLK_P with OPTC only for dcn401 [ Upstream commit 3c6c8d1a1e3f033f1abf84d6d54c268c35b0fcdd ] [WHY] DTBCLK_P is used to generate virtual pixel clock, and to drive the HPO stream encoder clock. Programming the required clock when enabling/disabling both components can cause issues. For example, if HPO is being disabled and clock source is changed to REFCLK, virtual pixel rate will then be wrong, causing issues in CRTC. [HOW] Only program the DTBCLK_P when programming CRTC, as its expected it will be enabled prior to HPO, and disabled after HPO in all valid cases. Reviewed-by: Alvin Lee Signed-off-by: Dillon Varone Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 874697e12793 ("drm/amd/display: Defer BW-optimization-blocked DRR adjustments") Signed-off-by: Sasha Levin commit e97e9ef4704e54bb72cee429d12c4b43cd6082c6 Author: Alexandre Frade Date: Thu May 22 16:29:06 2025 +0000 Linux 6.12.30-xanmod1 Signed-off-by: Alexandre Frade commit 5745d474b824ccfe7408dbe7817163a692fa9c75 Merge: 6be381b1d359 e0e2f7824338 Author: Alexandre Frade Date: Thu May 22 16:27:05 2025 +0000 Merge tag 'v6.12.30' into 6.12 This is the 6.12.30 stable release commit e0e2f78243385e7188a57fcfceb6a19f723f1dff Author: Greg Kroah-Hartman Date: Thu May 22 14:29:54 2025 +0200 Linux 6.12.30 Link: https://lore.kernel.org/r/20250520125810.036375422@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Brett Mastbergen Tested-by: Peter Schneider Tested-by: Markus Reichelt Tested-by: Mark Brown Tested-by: Hardik Garg Signed-off-by: Greg Kroah-Hartman commit 25e07c8403f4daad35cffc18d96e32a80a2a3222 Author: Alex Deucher Date: Thu May 1 13:46:46 2025 -0400 drm/amdgpu: fix pm notifier handling commit 4aaffc85751da5722e858e4333e8cf0aa4b6c78f upstream. Set the s3/s0ix and s4 flags in the pm notifier so that we can skip the resource evictions properly in pm prepare based on whether we are suspending or hibernating. Drop the eviction as processes are not frozen at this time, we we can end up getting stuck trying to evict VRAM while applications continue to submit work which causes the buffers to get pulled back into VRAM. v2: Move suspend flags out of pm notifier (Mario) Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4178 Fixes: 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notification callback support") Cc: Mario Limonciello Reviewed-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 06f2dcc241e7e5c681f81fbc46cacdf4bfd7d6d7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8e7583fb858c729b4e6b3c0aa724206a4892cc88 Author: Dan Carpenter Date: Wed Apr 23 16:08:23 2025 +0300 phy: tegra: xusb: remove a stray unlock commit 83c178470e0bf690d34c8c08440f2421b82e881c upstream. We used to take a lock in tegra186_utmi_bias_pad_power_on() but now we have moved the lock into the caller. Unfortunately, when we moved the lock this unlock was left behind and it results in a double unlock. Delete it now. Fixes: b47158fb4295 ("phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking") Signed-off-by: Dan Carpenter Reviewed-by: Jon Hunter Link: https://lore.kernel.org/r/aAjmR6To4EnvRl4G@stanley.mountain Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 5924b324468845fc795bd76f588f51d7ab4f202d Author: Andrei Kuchynski Date: Thu Apr 24 08:44:28 2025 +0000 usb: typec: ucsi: displayport: Fix deadlock commit 364618c89d4c57c85e5fc51a2446cd939bf57802 upstream. This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it. Cc: stable Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Signed-off-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250424084429.3220757-2-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman commit bca94cc345633e29ad61a7f1ade0bd035bd7d1f7 Author: Fabio Estevam Date: Mon May 19 13:32:30 2025 -0300 drm/tiny: panel-mipi-dbi: Use drm_client_setup_with_fourcc() commit 9c1798259b9420f38f1fa1b83e3d864c3eb1a83e upstream. Since commit 559358282e5b ("drm/fb-helper: Don't use the preferred depth for the BPP default"), RGB565 displays such as the CFAF240320X no longer render correctly: colors are distorted and the content is shown twice horizontally. This regression is due to the fbdev emulation layer defaulting to 32 bits per pixel, whereas the display expects 16 bpp (RGB565). As a result, the framebuffer data is incorrectly interpreted by the panel. Fix the issue by calling drm_client_setup_with_fourcc() with a format explicitly selected based on the display's bits-per-pixel value. For 16 bpp, use DRM_FORMAT_RGB565; for other values, fall back to the previous behavior. This ensures that the allocated framebuffer format matches the hardware expectations, avoiding color and layout corruption. Tested on a CFAF240320X display with an RGB565 configuration, confirming correct colors and layout after applying this patch. Cc: stable@vger.kernel.org Fixes: 559358282e5b ("drm/fb-helper: Don't use the preferred depth for the BPP default") Signed-off-by: Fabio Estevam Reviewed-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250417103458.2496790-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5ed066083fc303961345081de280ce912c5340c4 Author: Thomas Zimmermann Date: Mon May 19 13:32:29 2025 -0300 drm/panel-mipi-dbi: Run DRM default client setup commit 1b0caa5f5ac20bcaf82fc89a5c849b21ce3bfdf6 upstream. Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client. v5: - select DRM_CLIENT_SELECTION Signed-off-by: Thomas Zimmermann Cc: "Noralf Trønnes" Acked-by: Noralf Trønnes Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-32-tzimmermann@suse.de Signed-off-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman commit 25998ed87f0c8772bd5faf8ee92d831f1c69e1d0 Author: Thomas Zimmermann Date: Mon May 19 13:32:28 2025 -0300 drm/fbdev-dma: Support struct drm_driver.fbdev_probe commit 8998eedda2539d2528cfebdc7c17eed0ad35b714 upstream. Rework fbdev probing to support fbdev_probe in struct drm_driver and reimplement the old fb_probe callback on top of it. Provide an initializer macro for struct drm_driver that sets the callback according to the kernel configuration. This change allows the common fbdev client to run on top of DMA- based DRM drivers. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-6-tzimmermann@suse.de Signed-off-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman commit d22496de5049d9b8f5b6d8623682a56b3c3d7e18 Author: Neeraj Sanjay Kale Date: Mon Mar 10 17:32:31 2025 +0530 Bluetooth: btnxpuart: Fix kernel panic during FW release commit 1f77c05408c96bc0b58ae476a9cadc9e5b9cfd0f upstream. This fixes a kernel panic seen during release FW in a stress test scenario where WLAN and BT FW download occurs simultaneously, and due to a HW bug, chip sends out only 1 bootloader signatures. When driver receives the bootloader signature, it enters FW download mode, but since no consequtive bootloader signatures seen, FW file is not requested. After 60 seconds, when FW download times out, release_firmware causes a kernel panic. [ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : _raw_spin_lock+0x34/0x68 [ 2602.010201] lr : free_fw_priv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _raw_spin_lock+0x34/0x68 [ 2602.083364] release_firmware+0x48/0x6c [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hci_dev_open_sync+0xf0/0xa34 [ 2602.083391] hci_dev_open+0xd8/0x178 [ 2602.083399] hci_sock_ioctl+0x3b0/0x590 [ 2602.083405] sock_do_ioctl+0x60/0x118 [ 2602.083413] sock_ioctl+0x2f4/0x374 [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0 [ 2602.091437] invoke_syscall+0x48/0x110 [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0 [ 2602.091452] do_el0_svc+0x1c/0x28 [ 2602.091457] el0_svc+0x40/0xe4 [ 2602.091465] el0t_64_sync_handler+0x120/0x12c [ 2602.091470] el0t_64_sync+0x190/0x194 Fixes: e3c4891098c8 ("Bluetooth: btnxpuart: Handle FW Download Abort scenario") Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by: Neeraj Sanjay Kale Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Bin Lan Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman commit 7ca84f6a22d50bf8b31efe9eb05f9859947266d7 Author: Luca Ceresoli Date: Fri Mar 21 19:10:00 2025 +0100 iio: light: opt3001: fix deadlock due to concurrent flag access commit f063a28002e3350088b4577c5640882bf4ea17ea upstream. The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages. Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor") Cc: stable@vger.kernel.org Signed-off-by: Luca Ceresoli Link: https://patch.msgid.link/20250321-opt3001-irq-fix-v1-1-6c520d851562@bootlin.com Signed-off-by: Jonathan Cameron [Fixed conflict while applying on 6.12] Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 58517eae326e50ec208ffbf11a2bff90ac64a2cd Author: Jacek Lawrynowicz Date: Mon Sep 30 21:52:56 2024 +0200 accel/ivpu: Fix fw log printing commit 4bc988b47019536b3b1f7d9c5b83893c712d94d6 upstream. - Fix empty log detection that couldn't work without read_wrap_count - Start printing wrapped log from correct position (log_start) - Properly handle logs that are wrapped multiple times in reference to reader position - Don't add a newline when log buffer is wrapped - Always add a newline after printing a log buffer in case log does not end with one Reviewed-by: Tomasz Rusinowicz Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-6-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz Signed-off-by: Greg Kroah-Hartman commit 0923a7d55a85179744926b7c11768a81679cc4d4 Author: Jacek Lawrynowicz Date: Mon Sep 30 21:52:55 2024 +0200 accel/ivpu: Refactor functions in ivpu_fw_log.c commit 1fc1251149a76d3b75d7f4c94d9c4e081b7df6b4 upstream. Make function names more consistent and (arguably) readable in fw log code. Add fw_log_print_all_in_bo() that remove duplicated code in ivpu_fw_log_print(). Reviewed-by: Tomasz Rusinowicz Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-5-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz Signed-off-by: Greg Kroah-Hartman commit 1516c55872cc95998e90c72cb8b99d8f59f5fd87 Author: Tomasz Rusinowicz Date: Mon Sep 30 21:52:54 2024 +0200 accel/ivpu: Reset fw log on cold boot commit 4b4d9e394b6f45ac26ac6144b31604c76b7e3705 upstream. Add ivpu_fw_log_reset() that resets the read_index of all FW logs on cold boot so logs are properly read. Signed-off-by: Tomasz Rusinowicz Reviewed-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-4-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz Signed-off-by: Greg Kroah-Hartman commit 1c302f64ea0784d22519aa0a58b33b6659512036 Author: Jacek Lawrynowicz Date: Mon Sep 30 21:52:53 2024 +0200 accel/ivpu: Rename ivpu_log_level to fw_log_level commit 3a3fb8110c65d361cd9d750c9e16520f740c93f2 upstream. Rename module param ivpu_log_level to fw_log_level, so it is clear what log level is actually changed. Reviewed-by: Maciej Falkowski Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-3-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz Signed-off-by: Greg Kroah-Hartman commit 74953f93f47a45296cc2a3fd04e2a3202ff3fa53 Author: Kirill A. Shutemov Date: Tue May 6 16:32:07 2025 +0300 mm/page_alloc: fix race condition in unaccepted memory handling commit fefc075182275057ce607effaa3daa9e6e3bdc73 upstream. The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether. Link: https://lkml.kernel.org/r/20250506133207.1009676-1-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov Fixes: dcdfdd40fa82 ("mm: Add support for unaccepted memory") Link: https://lore.kernel.org/all/20250506092445.GBaBnVXXyvnazly6iF@fat_crate.local Reported-by: Borislav Petkov Tested-by: Borislav Petkov (AMD) Reported-by: Thomas Gleixner Cc: Vlastimil Babka Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Brendan Jackman Cc: Johannes Weiner Cc: [6.5+] Signed-off-by: Andrew Morton Signed-off-by: Kirill A. Shutemov Signed-off-by: Greg Kroah-Hartman commit 260ca2e9617fa990d3862eb9709ae47275fd6d80 Author: Daniele Ceraolo Spurio Date: Fri May 2 08:51:04 2025 -0700 drm/xe/gsc: do not flush the GSC worker from the reset path commit 03552d8ac0afcc080c339faa0b726e2c0e9361cb upstream. The workqueue used for the reset worker is marked as WQ_MEM_RECLAIM, while the GSC one isn't (and can't be as we need to do memory allocations in the gsc worker). Therefore, we can't flush the latter from the former. The reason why we had such a flush was to avoid interrupting either the GSC FW load or in progress GSC proxy operations. GSC proxy operations fall into 2 categories: 1) GSC proxy init: this only happens once immediately after GSC FW load and does not support being interrupted. The only way to recover from an interruption of the proxy init is to do an FLR and re-load the GSC. 2) GSC proxy request: this can happen in response to a request that the driver sends to the GSC. If this is interrupted, the GSC FW will timeout and the driver request will be failed, but overall the GSC will keep working fine. Flushing the work allowed us to avoid interruption in both cases (unless the hang came from the GSC engine itself, in which case we're toast anyway). However, a failure on a proxy request is tolerable if we're in a scenario where we're triggering a GT reset (i.e., something is already gone pretty wrong), so what we really need to avoid is interrupting the init flow, which we can do by polling on the register that reports when the proxy init is complete (as that ensure us that all the load and init operations have been completed). Note that during suspend we still want to do a flush of the worker to make sure it completes any operations involving the HW before the power is cut. v2: fix spelling in commit msg, rename waiter function (Julia) Fixes: dd0e89e5edc2 ("drm/xe/gsc: GSC FW load") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4830 Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Alan Previn Cc: # v6.8+ Reviewed-by: Julia Filipchuk Link: https://lore.kernel.org/r/20250502155104.2201469-1-daniele.ceraolospurio@intel.com (cherry picked from commit 12370bfcc4f0bdf70279ec5b570eb298963422b5) Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit 6b2d1fbd41469b64ad9923a449d9e4be2eef550c Author: Ritvik Budhiraja Date: Mon Nov 11 11:43:51 2024 +0000 CIFS: New mount option for cifs.upcall namespace resolution commit db363b0a1d9e6b9dc556296f1b1007aeb496a8cf upstream. In the current implementation, the SMB filesystem on a mount point can trigger upcalls from the kernel to the userspace to enable certain functionalities like spnego, dns_resolution, amongst others. These upcalls usually either happen in the context of the mount or in the context of an application/user. The upcall handler for cifs, cifs.upcall already has existing code which switches the namespaces to the caller's namespace before handling the upcall. This behaviour is expected for scenarios like multiuser mounts, but might not cover all single user scenario with services such as Kubernetes, where the mount can happen from different locations such as on the host, from an app container, or a driver pod which does the mount on behalf of a different pod. This patch introduces a new mount option called upcall_target, to customise the upcall behaviour. upcall_target can take 'mount' and 'app' as possible values. This aids use cases like Kubernetes where the mount happens on behalf of the application in another container altogether. Having this new mount option allows the mount command to specify where the upcall should happen: 'mount' for resolving the upcall to the host namespace, and 'app' for resolving the upcall to the ns of the calling thread. This will enable both the scenarios where the Kerberos credentials can be found on the application namespace or the host namespace to which just the mount operation is "delegated". Reviewed-by: Shyam Prasad Reviewed-by: Bharath S M Reviewed-by: Ronnie Sahlberg Signed-off-by: Ritvik Budhiraja Signed-off-by: Steve French Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 23dc14c52d84b02b39d816bf16a754c0e7d48f9c Author: Shuai Xue Date: Fri Apr 4 20:02:17 2025 +0800 dmaengine: idxd: Refactor remove call with idxd_cleanup() helper commit a409e919ca321cc0e28f8abf96fde299f0072a81 upstream. The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs. Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Cc: stable@vger.kernel.org Suggested-by: Vinicius Costa Gomes Signed-off-by: Shuai Xue Reviewed-by: Fenghua Yu Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250404120217.48772-10-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 017d4012dc05972ce95c2f487725a7a38e24552a Author: Shuai Xue Date: Fri Apr 4 20:02:15 2025 +0800 dmaengine: idxd: fix memory leak in error handling path of idxd_pci_probe commit 90022b3a6981ec234902be5dbf0f983a12c759fc upstream. Memory allocated for idxd is not freed if an error occurs during idxd_pci_probe(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error. Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Cc: stable@vger.kernel.org Signed-off-by: Shuai Xue Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20250404120217.48772-8-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 868dbce755ec92855362d213f47e045a8388361a Author: Shuai Xue Date: Fri Apr 4 20:02:14 2025 +0800 dmaengine: idxd: fix memory leak in error handling path of idxd_alloc commit 46a5cca76c76c86063000a12936f8e7875295838 upstream. Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error. Fixes: a8563a33a5e2 ("dmanegine: idxd: reformat opcap output to match bitmap_parse() input") Cc: stable@vger.kernel.org Signed-off-by: Shuai Xue Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20250404120217.48772-7-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 21f9f5cd9a0c75084d4369ba0b8c4f695c41dea7 Author: Shuai Xue Date: Fri Apr 4 20:02:16 2025 +0800 dmaengine: idxd: Add missing idxd cleanup to fix memory leak in remove call commit d5449ff1b04dfe9ed8e455769aa01e4c2ccf6805 upstream. The remove call stack is missing idxd cleanup to free bitmap, ida and the idxd_device. Call idxd_free() helper routines to make sure we exit gracefully. Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Cc: stable@vger.kernel.org Suggested-by: Vinicius Costa Gomes Signed-off-by: Shuai Xue Reviewed-by: Fenghua Yu Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250404120217.48772-9-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e0ba67b10d7c040bd34f06bf9b281ea6e3d29f26 Author: Shuai Xue Date: Fri Apr 4 20:02:13 2025 +0800 dmaengine: idxd: Add missing cleanups in cleanup internals commit 61d651572b6c4fe50c7b39a390760f3a910c7ccf upstream. The idxd_cleanup_internals() function only decreases the reference count of groups, engines, and wqs but is missing the step to release memory resources. To fix this, use the cleanup helper to properly release the memory resources. Fixes: ddf742d4f3f1 ("dmaengine: idxd: Add missing cleanup for early error out in probe call") Cc: stable@vger.kernel.org Signed-off-by: Shuai Xue Reviewed-by: Fenghua Yu Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250404120217.48772-6-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 80b02602279a3023f89f75e0fb1e3bfd68c72d84 Author: Shuai Xue Date: Fri Apr 4 20:02:12 2025 +0800 dmaengine: idxd: Add missing cleanup for early error out in idxd_setup_internals commit 61259fb96e023f7299c442c48b13e72c441fc0f2 upstream. The idxd_setup_internals() is missing some cleanup when things fail in the middle. Add the appropriate cleanup routines: - cleanup groups - cleanup enginces - cleanup wqs to make sure it exits gracefully. Fixes: defe49f96012 ("dmaengine: idxd: fix group conf_dev lifetime") Cc: stable@vger.kernel.org Suggested-by: Fenghua Yu Signed-off-by: Shuai Xue Reviewed-by: Fenghua Yu Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250404120217.48772-5-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 56e2f09083cf86f49f05a0587e2e8736cbf8c743 Author: Shuai Xue Date: Fri Apr 4 20:02:11 2025 +0800 dmaengine: idxd: fix memory leak in error handling path of idxd_setup_groups commit aa6f4f945b10eac57aed46154ae7d6fada7fccc7 upstream. Memory allocated for groups is not freed if an error occurs during idxd_setup_groups(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error. Fixes: defe49f96012 ("dmaengine: idxd: fix group conf_dev lifetime") Cc: stable@vger.kernel.org Signed-off-by: Shuai Xue Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20250404120217.48772-4-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 4958737c42e1bfb1effeedea5d003a27d6252999 Author: Shuai Xue Date: Fri Apr 4 20:02:10 2025 +0800 dmaengine: idxd: fix memory leak in error handling path of idxd_setup_engines commit 817bced19d1dbdd0b473580d026dc0983e30e17b upstream. Memory allocated for engines is not freed if an error occurs during idxd_setup_engines(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error. Fixes: 75b911309060 ("dmaengine: idxd: fix engine conf_dev lifetime") Cc: stable@vger.kernel.org Signed-off-by: Shuai Xue Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20250404120217.48772-3-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 5fcd392dae6d6aba7dc64ffdbb838ff191315da3 Author: Shuai Xue Date: Fri Apr 4 20:02:09 2025 +0800 dmaengine: idxd: fix memory leak in error handling path of idxd_setup_wqs commit 3fd2f4bc010cdfbc07dd21018dc65bd9370eb7a4 upstream. Memory allocated for wqs is not freed if an error occurs during idxd_setup_wqs(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error. Fixes: 7c5dd23e57c1 ("dmaengine: idxd: fix wq conf_dev 'struct device' lifetime") Fixes: 700af3a0a26c ("dmaengine: idxd: add 'struct idxd_dev' as wrapper for conf_dev") Fixes: de5819b99489 ("dmaengine: idxd: track enabled workqueues in bitmap") Fixes: b0325aefd398 ("dmaengine: idxd: add WQ operation cap restriction support") Cc: stable@vger.kernel.org Signed-off-by: Shuai Xue Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20250404120217.48772-2-xueshuai@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 6b5d770e4563306f318d4028c8db7005ec8e341f Author: Yemike Abhilash Chandra Date: Thu Apr 17 13:25:21 2025 +0530 dmaengine: ti: k3-udma: Use cap_mask directly from dma_device structure instead of a local copy commit 8ca9590c39b69b55a8de63d2b21b0d44f523b43a upstream. Currently, a local dma_cap_mask_t variable is used to store device cap_mask within udma_of_xlate(). However, the DMA_PRIVATE flag in the device cap_mask can get cleared when the last channel is released. This can happen right after storing the cap_mask locally in udma_of_xlate(), and subsequent dma_request_channel() can fail due to mismatch in the cap_mask. Fix this by removing the local dma_cap_mask_t variable and directly using the one from the dma_device structure. Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA") Cc: stable@vger.kernel.org Signed-off-by: Vaishnav Achath Acked-by: Peter Ujfalusi Reviewed-by: Udit Kumar Signed-off-by: Yemike Abhilash Chandra Link: https://lore.kernel.org/r/20250417075521.623651-1-y-abhilashchandra@ti.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 26e63b2fe30c61bd25981c6084f67a8af79945d0 Author: Ronald Wahl Date: Mon Apr 14 19:31:13 2025 +0200 dmaengine: ti: k3-udma: Add missing locking commit fca280992af8c2fbd511bc43f65abb4a17363f2f upstream. Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled: [ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]--- This commit adds the missing locking. Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA") Cc: Peter Ujfalusi Cc: Vignesh Raghavendra Cc: Vinod Koul Cc: dmaengine@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Ronald Wahl Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20250414173113.80677-1-rwahl@gmx.de Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit fe0756daad5201c77fe650695aa8e59036f5aa7e Author: Barry Song Date: Fri May 9 10:09:12 2025 +1200 mm: userfaultfd: correct dirty flags set for both present and swap pte commit 75cb1cca2c880179a11c7dd9380b6f14e41a06a4 upstream. As David pointed out, what truly matters for mremap and userfaultfd move operations is the soft dirty bit. The current comment and implementation—which always sets the dirty bit for present PTEs and fails to set the soft dirty bit for swap PTEs—are incorrect. This could break features like Checkpoint-Restore in Userspace (CRIU). This patch updates the behavior to correctly set the soft dirty bit for both present and swap PTEs in accordance with mremap. Link: https://lkml.kernel.org/r/20250508220912.7275-1-21cnbao@gmail.com Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by: Barry Song Reported-by: David Hildenbrand Closes: https://lore.kernel.org/linux-mm/02f14ee1-923f-47e3-a994-4950afb9afcc@redhat.com/ Acked-by: Peter Xu Reviewed-by: Suren Baghdasaryan Cc: Lokesh Gidra Cc: Andrea Arcangeli Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d005c8166528ee1e7de8d1594ec8d6d0c356039b Author: Nathan Chancellor Date: Wed May 7 21:47:45 2025 +0100 net: qede: Initialize qede_ll_ops with designated initializer commit 6b3ab7f2cbfaeb6580709cd8ef4d72cfd01bfde4 upstream. After a recent change [1] in clang's randstruct implementation to randomize structures that only contain function pointers, there is an error because qede_ll_ops get randomized but does not use a designated initializer for the first member: drivers/net/ethernet/qlogic/qede/qede_main.c:206:2: error: a randomized struct can only be initialized with a designated initializer 206 | { | ^ Explicitly initialize the common member using a designated initializer to fix the build. Cc: stable@vger.kernel.org Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Link: https://github.com/llvm/llvm-project/commit/04364fb888eea6db9811510607bed4b200bcb082 [1] Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20250507-qede-fix-clang-randstruct-v1-1-5ccc15626fba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 20d6e621be486f4021e44598421138a0e7315c1c Author: Steven Rostedt Date: Tue May 13 11:50:32 2025 -0400 ring-buffer: Fix persistent buffer when commit page is the reader page commit 1d6c39c89f617c9fec6bbae166e25b16a014f7c8 upstream. The ring buffer is made up of sub buffers (sometimes called pages as they are by default PAGE_SIZE). It has the following "pages": "tail page" - this is the page that the next write will write to "head page" - this is the page that the reader will swap the reader page with. "reader page" - This belongs to the reader, where it will swap the head page from the ring buffer so that the reader does not race with the writer. The writer may end up on the "reader page" if the ring buffer hasn't written more than one page, where the "tail page" and the "head page" are the same. The persistent ring buffer has meta data that points to where these pages exist so on reboot it can re-create the pointers to the cpu_buffer descriptor. But when the commit page is on the reader page, the logic is incorrect. The check to see if the commit page is on the reader page checked if the head page was the reader page, which would never happen, as the head page is always in the ring buffer. The correct check would be to test if the commit page is on the reader page. If that's the case, then it can exit out early as the commit page is only on the reader page when there's only one page of data in the buffer. There's no reason to iterate the ring buffer pages to find the "commit page" as it is already found. To trigger this bug: # echo 1 > /sys/kernel/tracing/instances/boot_mapped/events/syscalls/sys_enter_fchownat/enable # touch /tmp/x # chown sshd /tmp/x # reboot On boot up, the dmesg will have: Ring buffer meta [0] is from previous boot! Ring buffer meta [1] is from previous boot! Ring buffer meta [2] is from previous boot! Ring buffer meta [3] is from previous boot! Ring buffer meta [4] commit page not found Ring buffer meta [5] is from previous boot! Ring buffer meta [6] is from previous boot! Ring buffer meta [7] is from previous boot! Where the buffer on CPU 4 had a "commit page not found" error and that buffer is cleared and reset causing the output to be empty and the data lost. When it works correctly, it has: # cat /sys/kernel/tracing/instances/boot_mapped/trace_pipe <...>-1137 [004] ..... 998.205323: sys_enter_fchownat: __syscall_nr=0x104 (260) dfd=0xffffff9c (4294967196) filename=(0xffffc90000a0002c) user=0x3e8 (1000) group=0xffffffff (4294967295) flag=0x0 (0 Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250513115032.3e0b97f7@gandalf.local.home Fixes: 5f3b6e839f3ce ("ring-buffer: Validate boot range memory events") Reported-by: Tasos Sahanidis Tested-by: Tasos Sahanidis Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 2b81e76db3667d1f7f2ad44e9835cdaf8dea95a8 Author: Fedor Pchelkin Date: Tue May 6 14:55:39 2025 +0300 wifi: mt76: disable napi on driver removal commit 78ab4be549533432d97ea8989d2f00b508fa68d8 upstream. A warning on driver removal started occurring after commit 9dd05df8403b ("net: warn if NAPI instance wasn't shut down"). Disable tx napi before deleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way. Found by Linux Verification Center (linuxtesting.org). Fixes: 2ac515a5d74f ("mt76: mt76x02: use napi polling for tx cleanup") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Tested-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250506115540.19045-1-pchelkin@ispras.ru Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit ec5d9a750e916895426c4740d44b01fa77734811 Author: Jarkko Sakkinen Date: Mon Apr 7 15:28:05 2025 +0300 tpm: Mask TPM RC in tpm2_start_auth_session() commit 539fbab37881e32ba6a708a100de6db19e1e7e7d upstream. tpm2_start_auth_session() does not mask TPM RC correctly from the callers: [ 28.766528] tpm tpm0: A TPM error (2307) occurred start auth session Process TPM RCs inside tpm2_start_auth_session(), and map them to POSIX error codes. Cc: stable@vger.kernel.org # v6.10+ Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions") Reported-by: Herbert Xu Closes: https://lore.kernel.org/linux-integrity/Z_NgdRHuTKP6JK--@gondor.apana.org.au/ Reviewed-by: Stefano Garzarella Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit cac03fecbcc57048704f45268d1435f01a538bd6 Author: Aaron Kling Date: Tue May 6 13:36:59 2025 -0500 spi: tegra114: Use value to check for invalid delays commit e979a7c79fbc706f6dac913af379ef4caa04d3d5 upstream. A delay unit of 0 is a valid entry, thus it is not valid to check for unused delays. Instead, check the value field; if that is zero, the given delay is unset. Fixes: 4426e6b4ecf6 ("spi: tegra114: Don't fail set_cs_timing when delays are zero") Cc: stable@vger.kernel.org Signed-off-by: Aaron Kling Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20250506-spi-tegra114-fixup-v1-1-136dc2f732f3@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d0df124437cc50b88e4e61cd3230949e6049d18c Author: Jethro Donaldson Date: Thu May 15 01:23:23 2025 +1200 smb: client: fix memory leak during error handling for POSIX mkdir commit 1fe4a44b7fa3955bcb7b4067c07b778fe90d8ee7 upstream. The response buffer for the CREATE request handled by smb311_posix_mkdir() is leaked on the error path (goto err_free_rsp_buf) because the structure pointer *rsp passed to free_rsp_buf() is not assigned until *after* the error condition is checked. As *rsp is initialised to NULL, free_rsp_buf() becomes a no-op and the leak is instead reported by __kmem_cache_shutdown() upon subsequent rmmod of cifs.ko if (and only if) the error path has been hit. Pass rsp_iov.iov_base to free_rsp_buf() instead, similar to the code in other functions in smb2pdu.c for which *rsp is assigned late. Cc: stable@vger.kernel.org Signed-off-by: Jethro Donaldson Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bffc3038a28b9be7caffdaec53b08b15fa0d8b06 Author: Steve Siwinski Date: Thu May 8 16:01:22 2025 -0400 scsi: sd_zbc: block: Respect bio vector limits for REPORT ZONES buffer commit e8007fad5457ea547ca63bb011fdb03213571c7e upstream. The REPORT ZONES buffer size is currently limited by the HBA's maximum segment count to ensure the buffer can be mapped. However, the block layer further limits the number of iovec entries to 1024 when allocating a bio. To avoid allocation of buffers too large to be mapped, further restrict the maximum buffer size to BIO_MAX_INLINE_VECS. Replace the UIO_MAXIOV symbolic name with the more contextually appropriate BIO_MAX_INLINE_VECS. Fixes: b091ac616846 ("sd_zbc: Fix report zones buffer allocation") Cc: stable@vger.kernel.org Signed-off-by: Steve Siwinski Link: https://lore.kernel.org/r/20250508200122.243129-1-ssiwinski@atto.com Reviewed-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c450f648d0fc3fa01ebf16de70757f54b359735d Author: Claudiu Beznea Date: Wed May 7 15:50:32 2025 +0300 phy: renesas: rcar-gen3-usb2: Set timing registers only once commit 86e70849f4b2b4597ac9f7c7931f2a363774be25 upstream. phy-rcar-gen3-usb2 driver exports 4 PHYs. The timing registers are common to all PHYs. There is no need to set them every time a PHY is initialized. Set timing register only when the 1st PHY is initialized. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Reviewed-by: Lad Prabhakar Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250507125032.565017-6-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit c78a5693bd15f7a5f62f6c8621140fc646e73b89 Author: Claudiu Beznea Date: Wed May 7 15:50:28 2025 +0300 phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bind commit 54c4c58713aaff76c2422ff5750e557ab3b100d7 upstream. It has been observed on the Renesas RZ/G3S SoC that unbinding and binding the PHY driver leads to role autodetection failures. This issue occurs when PHY 3 is the first initialized PHY. PHY 3 does not have an interrupt associated with the USB2_INT_ENABLE register (as rcar_gen3_int_enable[3] = 0). As a result, rcar_gen3_init_otg() is called to initialize OTG without enabling PHY interrupts. To resolve this, add rcar_gen3_is_any_otg_rphy_initialized() and call it in role_store(), role_show(), and rcar_gen3_init_otg(). At the same time, rcar_gen3_init_otg() is only called when initialization for a PHY with interrupt bits is in progress. As a result, the struct rcar_gen3_phy::otg_initialized is no longer needed. Fixes: 549b6b55b005 ("phy: renesas: rcar-gen3-usb2: enable/disable independent irqs") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Reviewed-by: Lad Prabhakar Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250507125032.565017-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit ed0e7d31d09aa4829b5c73fc061726ca09cd7724 Author: Ma Ke Date: Mon Mar 3 15:27:39 2025 +0800 phy: Fix error handling in tegra_xusb_port_init commit b2ea5f49580c0762d17d80d8083cb89bc3acf74f upstream. If device_add() fails, do not use device_unregister() for error handling. device_unregister() consists two functions: device_del() and put_device(). device_unregister() should only be called after device_add() succeeded because device_del() undoes what device_add() does if successful. Change device_unregister() to put_device() call before returning from the function. As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable@vger.kernel.org Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support") Signed-off-by: Ma Ke Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20250303072739.3874987-1-make24@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 1db527f0cb8f677adadd4e28e5bc77aaf5d4e4c9 Author: Wayne Chang Date: Tue Apr 8 11:09:05 2025 +0800 phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking commit b47158fb42959c417ff2662075c0d46fb783d5d1 upstream. The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count. To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles. The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask. Cc: stable@vger.kernel.org Fixes: a30951d31b25 ("xhci: tegra: USB2 pad power controls") Signed-off-by: Wayne Chang Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20250408030905.990474-1-waynec@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit ce14aa00dd53570ed58dcf12098ea9eee50a414f Author: Steven Rostedt Date: Fri May 9 15:26:57 2025 -0400 tracing: samples: Initialize trace_array_printk() with the correct function commit 1b0c192c92ea1fe2dcb178f84adf15fe37c3e7c8 upstream. When using trace_array_printk() on a created instance, the correct function to use to initialize it is: trace_array_init_printk() Not trace_printk_init_buffer() The former is a proper function to use, the latter is for initializing trace_printk() and causes the NOTICE banner to be displayed. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Divya Indi Link: https://lore.kernel.org/20250509152657.0f6744d9@gandalf.local.home Fixes: 89ed42495ef4a ("tracing: Sample module to demonstrate kernel access to Ftrace instances.") Fixes: 38ce2a9e33db6 ("tracing: Add trace_array_init_printk() to initialize instance trace_printk() buffers") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 589c9e66bd475be43625104cc24d6cbb77abb582 Author: pengdonglin Date: Mon May 12 17:42:46 2025 +0800 ftrace: Fix preemption accounting for stacktrace filter command commit 11aff32439df6ca5b3b891b43032faf88f4a6a29 upstream. The preemption count of the stacktrace filter command to trace ksys_read is consistently incorrect: $ echo ksys_read:stacktrace > set_ftrace_filter <...>-453 [004] ...1. 38.308956: => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe The root cause is that the trace framework disables preemption when invoking the filter command callback in function_trace_probe_call: preempt_disable_notrace(); probe_ops->func(ip, parent_ip, probe_opsbe->tr, probe_ops, probe->data); preempt_enable_notrace(); Use tracing_gen_ctx_dec() to account for the preempt_disable_notrace(), which will output the correct preemption count: $ echo ksys_read:stacktrace > set_ftrace_filter <...>-410 [006] ..... 31.420396: => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe Cc: stable@vger.kernel.org Fixes: 36590c50b2d07 ("tracing: Merge irqflags + preempt counter.") Link: https://lore.kernel.org/20250512094246.1167956-2-dolinux.peng@gmail.com Signed-off-by: pengdonglin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 7d353da580c5f3deac2c61035aab4d720dc2d421 Author: pengdonglin Date: Mon May 12 17:42:45 2025 +0800 ftrace: Fix preemption accounting for stacktrace trigger command commit e333332657f615ac2b55aa35565c4a882018bbe9 upstream. When using the stacktrace trigger command to trace syscalls, the preemption count was consistently reported as 1 when the system call event itself had 0 ("."). For example: root@ubuntu22-vm:/sys/kernel/tracing/events/syscalls/sys_enter_read $ echo stacktrace > trigger $ echo 1 > enable sshd-416 [002] ..... 232.864910: sys_read(fd: a, buf: 556b1f3221d0, count: 8000) sshd-416 [002] ...1. 232.864913: => ftrace_syscall_enter => syscall_trace_enter => do_syscall_64 => entry_SYSCALL_64_after_hwframe The root cause is that the trace framework disables preemption in __DO_TRACE before invoking the trigger callback. Use the tracing_gen_ctx_dec() that will accommodate for the increase of the preemption count in __DO_TRACE when calling the callback. The result is the accurate reporting of: sshd-410 [004] ..... 210.117660: sys_read(fd: 4, buf: 559b725ba130, count: 40000) sshd-410 [004] ..... 210.117662: => ftrace_syscall_enter => syscall_trace_enter => do_syscall_64 => entry_SYSCALL_64_after_hwframe Cc: stable@vger.kernel.org Fixes: ce33c845b030c ("tracing: Dump stacktrace trigger to the corresponding instance") Link: https://lore.kernel.org/20250512094246.1167956-1-dolinux.peng@gmail.com Signed-off-by: pengdonglin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 511ceee89966ce906ca8989523e1a67ba6de44c1 Author: Nathan Chancellor Date: Tue May 6 14:02:01 2025 -0700 kbuild: Disable -Wdefault-const-init-unsafe commit d0afcfeb9e3810ec89d1ffde1a0e36621bb75dca upstream. A new on by default warning in clang [1] aims to flags instances where const variables without static or thread local storage or const members in aggregate types are not initialized because it can lead to an indeterminate value. This is quite noisy for the kernel due to instances originating from header files such as: drivers/gpu/drm/i915/gt/intel_ring.h:62:2: error: default initialization of an object of type 'typeof (ring->size)' (aka 'const unsigned int') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe] 62 | typecheck(typeof(ring->size), next); | ^ include/linux/typecheck.h:10:9: note: expanded from macro 'typecheck' 10 | ({ type __dummy; \ | ^ include/net/ip.h:478:14: error: default initialization of an object of type 'typeof (rt->dst.expires)' (aka 'const unsigned long') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe] 478 | if (mtu && time_before(jiffies, rt->dst.expires)) | ^ include/linux/jiffies.h:138:26: note: expanded from macro 'time_before' 138 | #define time_before(a,b) time_after(b,a) | ^ include/linux/jiffies.h:128:3: note: expanded from macro 'time_after' 128 | (typecheck(unsigned long, a) && \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ include/linux/list.h:409:27: warning: default initialization of an object of type 'union (unnamed union at include/linux/list.h:409:27)' with const member leaves the object uninitialized [-Wdefault-const-init-field-unsafe] 409 | struct list_head *next = smp_load_acquire(&head->next); | ^ include/asm-generic/barrier.h:176:29: note: expanded from macro 'smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^ arch/arm64/include/asm/barrier.h:164:59: note: expanded from macro '__smp_load_acquire' 164 | union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u; \ | ^ include/linux/list.h:409:27: note: member '__val' declared 'const' here crypto/scatterwalk.c:66:22: error: default initialization of an object of type 'struct scatter_walk' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 66 | struct scatter_walk walk; | ^ include/crypto/algapi.h:112:15: note: member 'addr' declared 'const' here 112 | void *const addr; | ^ fs/hugetlbfs/inode.c:733:24: error: default initialization of an object of type 'struct vm_area_struct' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 733 | struct vm_area_struct pseudo_vma; | ^ include/linux/mm_types.h:803:20: note: member 'vm_flags' declared 'const' here 803 | const vm_flags_t vm_flags; | ^ Silencing the instances from typecheck.h is difficult because '= {}' is not available in older but supported compilers and '= {0}' would cause warnings about a literal 0 being treated as NULL. While it might be possible to come up with a local hack to silence the warning for clang-21+, it may not be worth it since -Wuninitialized will still trigger if an uninitialized const variable is actually used. In all audited cases of the "field" variant of the warning, the members are either not used in the particular call path, modified through other means such as memset() / memcpy() because the containing object is not const, or are within a union with other non-const members. Since this warning does not appear to have a high signal to noise ratio, just disable it. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/576161cb6069e2c7656a8ef530727a0f4aefff30 [1] Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/CA+G9fYuNjKcxFKS_MKPRuga32XbndkLGcY-PVuoSwzv6VWbY=w@mail.gmail.com/ Reported-by: Marcus Seyfarth Closes: https://github.com/ClangBuiltLinux/linux/issues/2088 Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 899e014e6847de8f2c4959373a7a7fa8b97d77cb Author: Michael Kelley Date: Mon May 12 17:06:04 2025 -0700 Drivers: hv: vmbus: Remove vmbus_sendpacket_pagebuffer() commit 45a442fe369e6c4e0b4aa9f63b31c3f2f9e2090e upstream. With the netvsc driver changed to use vmbus_sendpacket_mpb_desc() instead of vmbus_sendpacket_pagebuffer(), the latter has no remaining callers. Remove it. Cc: # 6.1.x Signed-off-by: Michael Kelley Link: https://patch.msgid.link/20250513000604.1396-6-mhklinux@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4400b05ffabcc1dc0bc7d4883b2b37991d671707 Author: Michael Kelley Date: Mon May 12 17:06:00 2025 -0700 Drivers: hv: Allow vmbus_sendpacket_mpb_desc() to create multiple ranges commit 380b75d3078626aadd0817de61f3143f5db6e393 upstream. vmbus_sendpacket_mpb_desc() is currently used only by the storvsc driver and is hardcoded to create a single GPA range. To allow it to also be used by the netvsc driver to create multiple GPA ranges, no longer hardcode as having a single GPA range. Allow the calling driver to specify the rangecount in the supplied descriptor. Update the storvsc driver to reflect this new approach. Cc: # 6.1.x Signed-off-by: Michael Kelley Link: https://patch.msgid.link/20250513000604.1396-2-mhklinux@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 02a68f11ba84b6d6c983b909771b69977b16fab4 Author: Dragan Simic Date: Mon Mar 24 12:00:43 2025 +0100 arm64: dts: rockchip: Remove overdrive-mode OPPs from RK3588J SoC dtsi commit e0bd7ecf6b2dc71215af699dffbf14bf0bc3d978 upstream. The differences in the vendor-approved CPU and GPU OPPs for the standard Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2] come from the latter, presumably, supporting an extended temperature range that's usually associated with industrial applications, despite the two SoC variant datasheets specifying the same upper limit for the allowed ambient temperature for both variants. However, the lower temperature limit is specified much lower for the RK3588J variant. [1][2] To be on the safe side and to ensure maximum longevity of the RK3588J SoCs, only the CPU and GPU OPPs that are declared by the vendor to be always safe for this SoC variant may be provided. As explained by the vendor [3] and according to the RK3588J datasheet, [2] higher-frequency/higher-voltage CPU and GPU OPPs can be used as well, but at the risk of reducing the SoC lifetime expectancy. Presumably, using the higher OPPs may be safe only when not enjoying the assumed extended temperature range that the RK3588J, as an SoC variant targeted specifically at higher-temperature, industrial applications, is made (or binned) for. Anyone able to keep their RK3588J-based board outside the above-presumed extended temperature range at all times, and willing to take the associated risk of possibly reducing the SoC lifetime expectancy, is free to apply a DT overlay that adds the higher CPU and GPU OPPs. With all this and the downstream RK3588(J) DT definitions [4][5] in mind, let's delete the RK3588J CPU and GPU OPPs that are not considered belonging to the normal operation mode for this SoC variant. To quote the RK3588J datasheet [2], "normal mode means the chipset works under safety voltage and frequency; for the industrial environment, highly recommend to keep in normal mode, the lifetime is reasonably guaranteed", while "overdrive mode brings higher frequency, and the voltage will increase accordingly; under the overdrive mode for a long time, the chipset may shorten the lifetime, especially in high-temperature condition". To sum the RK3588J datasheet [2] and the vendor-provided DTs up, [4][5] the maximum allowed CPU core, GPU and NPU frequencies are as follows: IP core | Normal mode | Overdrive mode ------------+-------------+---------------- Cortex-A55 | 1,296 MHz | 1,704 MHz Cortex-A76 | 1,608 MHz | 2,016 MHz GPU | 700 MHz | 850 MHz NPU | 800 MHz | 950 MHz Unfortunately, when it comes to the actual voltages for the RK3588J CPU and GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the downstream kernel code. [4][5] The RK3588J datasheet states that "the max. working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the downstream kernel code actually allows voltage ranges that go up to 0.95 V, which is still within the voltage range allowed by the datasheet. However, the RK3588J datasheet also tells us to "strictly refer to the software configuration of SDK and the hardware reference design", so let's embrace the voltage ranges provided by the downstream kernel code, which also prevents the undesirable theoretical outcome of ending up with no usable OPPs on a particular board, as a result of the board's voltage regulator(s) being unable to deliver the exact voltages, for whatever reason. The above-described voltage ranges for the RK3588J CPU OPPs remain taken from the downstream kernel code [4][5] by picking the highest, worst-bin values, which ensure that all RK3588J bins will work reliably. Yes, with some power inevitably wasted as unnecessarily generated heat, but the reliability is paramount, together with the longevity. This deficiency may be revisited separately at some point in the future. The provided RK3588J CPU OPPs follow the slightly debatable "provide only the highest-frequency OPP from the same-voltage group" approach that's been established earlier, [6] as a result of the "same-voltage, lower-frequency" OPPs being considered inefficient from the IPA governor's standpoint, which may also be revisited separately at some point in the future. [1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf [2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf [3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u [4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi [5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi [6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/ Fixes: 667885a68658 ("arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j") Fixes: a7b2070505a2 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j") Cc: stable@vger.kernel.org Cc: Heiko Stuebner Cc: Alexey Charkov Helped-by: Quentin Schulz Reviewed-by: Quentin Schulz Signed-off-by: Dragan Simic Link: https://lore.kernel.org/r/eeec0d30d79b019d111b3f0aa2456e69896b2caa.1742813866.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 7f2e784f27bbc48558dcfdadcc50a6fb3dee2695 Author: Christian Hewitt Date: Sat May 3 08:44:43 2025 +0000 arm64: dts: amlogic: dreambox: fix missing clkc_audio node commit 0f67578587bb9e5a8eecfcdf6b8a501b5bd90526 upstream. Add the clkc_audio node to fix audio support on Dreambox One/Two. Fixes: 83a6f4c62cb1 ("arm64: dts: meson: add initial support for Dreambox One/Two") CC: stable@vger.kernel.org Suggested-by: Emanuel Strobel Signed-off-by: Christian Hewitt Reviewed-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20250503084443.3704866-1-christianshewitt@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Greg Kroah-Hartman commit b1d6694b39ec5030b7708cc009ba6d48c1ec5d60 Author: Michael Kelley Date: Mon May 12 17:06:03 2025 -0700 hv_netvsc: Remove rmsg_pgcnt commit 5bbc644bbf4e97a05bc0cb052189004588ff8a09 upstream. init_page_array() now always creates a single page buffer array entry for the rndis message, even if the rndis message crosses a page boundary. As such, the number of page buffer array entries used for the rndis message must no longer be tracked -- it is always just 1. Remove the rmsg_pgcnt field and use "1" where the value is needed. Cc: # 6.1.x Signed-off-by: Michael Kelley Link: https://patch.msgid.link/20250513000604.1396-5-mhklinux@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7a508c604cd3528fa3df0903cb5ed87bd622de84 Author: Michael Kelley Date: Mon May 12 17:06:02 2025 -0700 hv_netvsc: Preserve contiguous PFN grouping in the page buffer array commit 41a6328b2c55276f89ea3812069fd7521e348bbf upstream. Starting with commit dca5161f9bd0 ("hv_netvsc: Check status in SEND_RNDIS_PKT completion message") in the 6.3 kernel, the Linux driver for Hyper-V synthetic networking (netvsc) occasionally reports "nvsp_rndis_pkt_complete error status: 2".[1] This error indicates that Hyper-V has rejected a network packet transmit request from the guest, and the outgoing network packet is dropped. Higher level network protocols presumably recover and resend the packet so there is no functional error, but performance is slightly impacted. Commit dca5161f9bd0 is not the cause of the error -- it only added reporting of an error that was already happening without any notice. The error has presumably been present since the netvsc driver was originally introduced into Linux. The root cause of the problem is that the netvsc driver in Linux may send an incorrectly formatted VMBus message to Hyper-V when transmitting the network packet. The incorrect formatting occurs when the rndis header of the VMBus message crosses a page boundary due to how the Linux skb head memory is aligned. In such a case, two PFNs are required to describe the location of the rndis header, even though they are contiguous in guest physical address (GPA) space. Hyper-V requires that two rndis header PFNs be in a single "GPA range" data struture, but current netvsc code puts each PFN in its own GPA range, which Hyper-V rejects as an error. The incorrect formatting occurs only for larger packets that netvsc must transmit via a VMBus "GPA Direct" message. There's no problem when netvsc transmits a smaller packet by copying it into a pre- allocated send buffer slot because the pre-allocated slots don't have page crossing issues. After commit 14ad6ed30a10 ("net: allow small head cache usage with large MAX_SKB_FRAGS values") in the 6.14-rc4 kernel, the error occurs much more frequently in VMs with 16 or more vCPUs. It may occur every few seconds, or even more frequently, in an ssh session that outputs a lot of text. Commit 14ad6ed30a10 subtly changes how skb head memory is allocated, making it much more likely that the rndis header will cross a page boundary when the vCPU count is 16 or more. The changes in commit 14ad6ed30a10 are perfectly valid -- they just had the side effect of making the netvsc bug more prominent. Current code in init_page_array() creates a separate page buffer array entry for each PFN required to identify the data to be transmitted. Contiguous PFNs get separate entries in the page buffer array, and any information about contiguity is lost. Fix the core issue by having init_page_array() construct the page buffer array to represent contiguous ranges rather than individual pages. When these ranges are subsequently passed to netvsc_build_mpb_array(), it can build GPA ranges that contain multiple PFNs, as required to avoid the error "nvsp_rndis_pkt_complete error status: 2". If instead the network packet is sent by copying into a pre-allocated send buffer slot, the copy proceeds using the contiguous ranges rather than individual pages, but the result of the copying is the same. Also fix rndis_filter_send_request() to construct a contiguous range, since it has its own page buffer array. This change has a side benefit in CoCo VMs in that netvsc_dma_map() calls dma_map_single() on each contiguous range instead of on each page. This results in fewer calls to dma_map_single() but on larger chunks of memory, which should reduce contention on the swiotlb. Since the page buffer array now contains one entry for each contiguous range instead of for each individual page, the number of entries in the array can be reduced, saving 208 bytes of stack space in netvsc_xmit() when MAX_SKG_FRAGS has the default value of 17. [1] https://bugzilla.kernel.org/show_bug.cgi?id=217503 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217503 Cc: # 6.1.x Signed-off-by: Michael Kelley Link: https://patch.msgid.link/20250513000604.1396-4-mhklinux@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 24f05522c1c1f7c66a9d90cb978afd28c67b180c Author: Michael Kelley Date: Mon May 12 17:06:01 2025 -0700 hv_netvsc: Use vmbus_sendpacket_mpb_desc() to send VMBus messages commit 4f98616b855cb0e3b5917918bb07b44728eb96ea upstream. netvsc currently uses vmbus_sendpacket_pagebuffer() to send VMBus messages. This function creates a series of GPA ranges, each of which contains a single PFN. However, if the rndis header in the VMBus message crosses a page boundary, the netvsc protocol with the host requires that both PFNs for the rndis header must be in a single "GPA range" data structure, which isn't possible with vmbus_sendpacket_pagebuffer(). As the first step in fixing this, add a new function netvsc_build_mpb_array() to build a VMBus message with multiple GPA ranges, each of which may contain multiple PFNs. Use vmbus_sendpacket_mpb_desc() to send this VMBus message to the host. There's no functional change since higher levels of netvsc don't maintain or propagate knowledge of contiguous PFNs. Based on its input, netvsc_build_mpb_array() still produces a separate GPA range for each PFN and the behavior is the same as with vmbus_sendpacket_pagebuffer(). But the groundwork is laid for a subsequent patch to provide the necessary grouping. Cc: # 6.1.x Signed-off-by: Michael Kelley Link: https://patch.msgid.link/20250513000604.1396-3-mhklinux@outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fe1bebd0edb22e3536cbc920ec713331d1367ad4 Author: Hyejeong Choi Date: Mon May 12 21:06:38 2025 -0500 dma-buf: insert memory barrier before updating num_fences commit 72c7d62583ebce7baeb61acce6057c361f73be4a upstream. smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered. Signed-off-by: Hyejeong Choi Fixes: a590d0fdbaa5 ("dma-buf: Update reservation shared_count after adding the new fence") CC: stable@vger.kernel.org Reviewed-by: Christian König Link: https://lore.kernel.org/r/20250513020638.GA2329653@au1-maretx-p37.eng.sarc.samsung.com Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 93152dac0ba7217f058e1276ed5cdc5455db44b1 Author: Nicolas Chauvet Date: Thu May 15 12:21:32 2025 +0200 ALSA: usb-audio: Add sample rate quirk for Microdia JP001 USB Camera commit 7b9938a14460e8ec7649ca2e80ac0aae9815bf02 upstream. Microdia JP001 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x84". This patch adds the USB ID to quirks.c and avoids those error messages. usb 7-4: New USB device found, idVendor=0c45, idProduct=636b, bcdDevice= 1.00 usb 7-4: New USB device strings: Mfr=2, Product=1, SerialNumber=3 usb 7-4: Product: JP001 usb 7-4: Manufacturer: JP001 usb 7-4: SerialNumber: JP001 usb 7-4: 3:1: cannot get freq at ep 0x84 Cc: Signed-off-by: Nicolas Chauvet Link: https://patch.msgid.link/20250515102132.73062-1-kwizart@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c88f4ff5354b416aa32d05155e6e3f5ee3fc7c35 Author: Christian Heusel Date: Mon May 12 22:23:37 2025 +0200 ALSA: usb-audio: Add sample rate quirk for Audioengine D1 commit 2b24eb060c2bb9ef79e1d3bcf633ba1bc95215d6 upstream. A user reported on the Arch Linux Forums that their device is emitting the following message in the kernel journal, which is fixed by adding the quirk as submitted in this patch: > kernel: usb 1-2: current rate 8436480 is different from the runtime rate 48000 There also is an entry for this product line added long time ago. Their specific device has the following ID: $ lsusb | grep Audio Bus 001 Device 002: ID 1101:0003 EasyPass Industrial Co., Ltd Audioengine D1 Link: https://bbs.archlinux.org/viewtopic.php?id=305494 Fixes: 93f9d1a4ac593 ("ALSA: usb-audio: Apply sample rate quirk for Audioengine D1") Cc: stable@vger.kernel.org Signed-off-by: Christian Heusel Link: https://patch.msgid.link/20250512-audioengine-quirk-addition-v1-1-4c370af6eff7@heusel.eu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f8302100f42bf87e8bfbbb312044d5a2ef1bbe8c Author: Wentao Liang Date: Wed May 14 17:24:44 2025 +0800 ALSA: es1968: Add error handling for snd_pcm_hw_constraint_pow2() commit 9e000f1b7f31684cc5927e034360b87ac7919593 upstream. The function snd_es1968_capture_open() calls the function snd_pcm_hw_constraint_pow2(), but does not check its return value. A proper implementation can be found in snd_cx25821_pcm_open(). Add error handling for snd_pcm_hw_constraint_pow2() and propagate its error code. Fixes: b942cf815b57 ("[ALSA] es1968 - Fix stuttering capture") Cc: stable@vger.kernel.org # v2.6.22 Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20250514092444.331-1-vulab@iscas.ac.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7f8d77f654266aaf72946ac1962de935e50ceaa8 Author: Jeremy Linton Date: Wed May 7 21:30:25 2025 -0500 ACPI: PPTT: Fix processor subtable walk commit adfab6b39202481bb43286fff94def4953793fdb upstream. The original PPTT code had a bug where the processor subtable length was not correctly validated when encountering a truncated acpi_pptt_processor node. Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls") attempted to fix this by validating the size is as large as the acpi_pptt_processor node structure. This introduced a regression where the last processor node in the PPTT table is ignored if it doesn't contain any private resources. That results errors like: ACPI PPTT: PPTT table found, but unable to locate core XX (XX) ACPI: SPE must be homogeneous Furthermore, it fails in a common case where the node length isn't equal to the acpi_pptt_processor structure size, leaving the original bug in a modified form. Correct the regression by adjusting the loop termination conditions as suggested by the bug reporters. An additional check performed after the subtable node type is detected, validates the acpi_pptt_processor node is fully contained in the PPTT table. Repeating the check in acpi_pptt_leaf_node() is largely redundant as the node is already known to be fully contained in the table. The case where a final truncated node's parent property is accepted, but the node itself is rejected should not be considered a bug. Fixes: 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls") Reported-by: Maximilian Heyne Closes: https://lore.kernel.org/linux-acpi/20250506-draco-taped-15f475cd@mheyne-amazon/ Reported-by: Yicong Yang Closes: https://lore.kernel.org/linux-acpi/20250507035124.28071-1-yangyicong@huawei.com/ Signed-off-by: Jeremy Linton Tested-by: Yicong Yang Reviewed-by: Sudeep Holla Tested-by: Maximilian Heyne Cc: All applicable # 7ab4f0e37a0f4: ACPI PPTT: Fix coding mistakes ... Link: https://patch.msgid.link/20250508023025.1301030-1-jeremy.linton@arm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a348ff3f5b697c7ea983571e901b779ea6bab179 Author: Emanuele Ghidoli Date: Mon May 12 11:54:41 2025 +0200 gpio: pca953x: fix IRQ storm on system wake up commit 3e38f946062b4845961ab86b726651b4457b2af8 upstream. If an input changes state during wake-up and is used as an interrupt source, the IRQ handler reads the volatile input register to clear the interrupt mask and deassert the IRQ line. However, the IRQ handler is triggered before access to the register is granted, causing the read operation to fail. As a result, the IRQ handler enters a loop, repeatedly printing the "failed reading register" message, until `pca953x_resume()` is eventually called, which restores the driver context and enables access to registers. Fix by disabling the IRQ line before entering suspend mode, and re-enabling it after the driver context is restored in `pca953x_resume()`. An IRQ can be disabled with disable_irq() and still wake the system as long as the IRQ has wake enabled, so the wake-up functionality is preserved. Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle") Cc: stable@vger.kernel.org Signed-off-by: Emanuele Ghidoli Signed-off-by: Francesco Dolcini Reviewed-by: Andy Shevchenko Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20250512095441.31645-1-francesco@dolcini.it Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit f0c0b8e6bc2658a71c02136e4167491fb577f871 Author: Alexey Makhalov Date: Tue Mar 18 00:40:31 2025 +0000 MAINTAINERS: Update Alexey Makhalov's email address commit 386cd3dcfd63491619b4034b818737fc0219e128 upstream. Fix a typo in an email address. Closes: https://lore.kernel.org/all/20240925-rational-succinct-vulture-cca9fb@lemur/T/ Reported-by: Konstantin Ryabitsev Reported-by: Juergen Gross Signed-off-by: Alexey Makhalov Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250318004031.2703923-1-alexey.makhalov@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 64a33088adf2b4b23f34566d18ac73e8b4f64243 Author: Wayne Lin Date: Tue May 13 11:20:24 2025 +0800 drm/amd/display: Avoid flooding unnecessary info messages commit d33724ffb743d3d2698bd969e29253ae0cff9739 upstream. It's expected that we'll encounter temporary exceptions during aux transactions. Adjust logging from drm_info to drm_dbg_dp to prevent flooding with unnecessary log messages. Fixes: 3637e457eb00 ("drm/amd/display: Fix wrong handling for AUX_DEFER case") Cc: Mario Limonciello Cc: Alex Deucher Signed-off-by: Wayne Lin Acked-by: Alex Deucher Link: https://lore.kernel.org/r/20250513032026.838036-1-Wayne.Lin@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 9a9c3e1fe5256da14a0a307dff0478f90c55fc8c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2d125a1f0d61bf224ed7fe6ce2f4f7d4f37b4c61 Author: Wayne Lin Date: Fri Apr 25 14:44:02 2025 +0800 drm/amd/display: Correct the reply value when AUX write incomplete commit d433981385c62c72080e26f1c00a961d18b233be upstream. [Why] Now forcing aux->transfer to return 0 when incomplete AUX write is inappropriate. It should return bytes have been transferred. [How] aux->transfer is asked not to change original msg except reply field of drm_dp_aux_msg structure. Copy the msg->buffer when it's write request, and overwrite the first byte when sink reply 1 byte indicating partially written byte number. Then we can return the correct value without changing the original msg. Fixes: 3637e457eb00 ("drm/amd/display: Fix wrong handling for AUX_DEFER case") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Ray Wu Signed-off-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 7ac37f0dcd2e0b729fa7b5513908dc8ab802b540) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8d71c3231b33e24a911b8f2d8c3a17ee40aa32d5 Author: Philip Yang Date: Wed May 7 11:04:32 2025 -0400 drm/amdgpu: csa unmap use uninterruptible lock commit a0fa7873f2f869087b1e7793f7fac3713a1e3afe upstream. After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace. Change to use uninterruptible wait lock fix the issue. WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0 Signed-off-by: Philip Yang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e54f20c5a17e8dff4bb54f4f88ec098dc905ee41 Author: Tim Huang Date: Thu May 8 13:37:35 2025 +0800 drm/amdgpu: fix incorrect MALL size for GFX1151 commit 2d73b0845ab3963856e857b810600e5594bc29f4 upstream. On GFX1151, the reported MALL cache size reflects only half of its actual size; this adjustment corrects the discrepancy. Signed-off-by: Tim Huang Acked-by: Alex Deucher Reviewed-by: Yifan Zhang Signed-off-by: Alex Deucher (cherry picked from commit 0a5c060b593ad152318f89e5564bfdfcff8a6ac0) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c75f3f9cbfb7a84254285c587840afe4494d6992 Author: Melissa Wen Date: Tue Apr 22 11:58:11 2025 -0300 Revert "drm/amd/display: Hardware cursor changes color when switched to software cursor" commit fe14c0f096f58d2569e587e9f4b05d772272bbb4 upstream. This reverts commit 272e6aab14bbf98d7a06b2b1cd6308a02d4a10a1. Applying degamma curve to the cursor by default breaks Linux userspace expectation. On Linux, AMD display manager enables cursor degamma ROM just for implict sRGB on HW versions where degamma is split into two blocks: degamma ROM for pre-defined TFs and `gamma correction` for user/custom curves, and degamma ROM settings doesn't apply to cursor plane. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1513 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2803 Reported-by: Michel Dänzer Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4144 Signed-off-by: Melissa Wen Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit f6a305d4748801a6c799ae9375b2ecff3aed094b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3ee6399854252affd15f69c722315457a139fd0c Author: Kyoji Ogasawara Date: Fri May 9 19:26:31 2025 +0900 btrfs: add back warning for mount option commit values exceeding 300 commit 4ce2affc6ef9f84b4aebbf18bd5c57397b6024eb upstream. The Btrfs documentation states that if the commit value is greater than 300 a warning should be issued. The warning was accidentally lost in the new mount API update. Fixes: 6941823cc878 ("btrfs: remove old mount API code") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Qu Wenruo Reviewed-by: Anand Jain Signed-off-by: Kyoji Ogasawara Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bf804f34adfb701ce8a77a1a330a6b44629f7ab5 Author: Boris Burkov Date: Wed May 7 12:42:24 2025 -0700 btrfs: fix folio leak in submit_one_async_extent() commit a0fd1c6098633f9a95fc2f636383546c82b704c3 upstream. If btrfs_reserve_extent() fails while submitting an async_extent for a compressed write, then we fail to call free_async_extent_pages() on the async_extent and leak its folios. A likely cause for such a failure would be btrfs_reserve_extent() failing to find a large enough contiguous free extent for the compressed extent. I was able to reproduce this by: 1. mount with compress-force=zstd:3 2. fallocating most of a filesystem to a big file 3. fragmenting the remaining free space 4. trying to copy in a file which zstd would generate large compressed extents for (vmlinux worked well for this) Step 4. hits the memory leak and can be repeated ad nauseam to eventually exhaust the system memory. Fix this by detecting the case where we fallback to uncompressed submission for a compressed async_extent and ensuring that we call free_async_extent_pages(). Fixes: 131a821a243f ("btrfs: fallback if compressed IO fails for ENOSPC") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana Co-developed-by: Josef Bacik Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6ea6cea17ff8609952b5d6c769c01817cc58be46 Author: Filipe Manana Date: Mon May 5 16:03:16 2025 +0100 btrfs: fix discard worker infinite loop after disabling discard commit 54db6d1bdd71fa90172a2a6aca3308bbf7fa7eb5 upstream. If the discard worker is running and there's currently only one block group, that block group is a data block group, it's in the unused block groups discard list and is being used (it got an extent allocated from it after becoming unused), the worker can end up in an infinite loop if a transaction abort happens or the async discard is disabled (during remount or unmount for example). This happens like this: 1) Task A, the discard worker, is at peek_discard_list() and find_next_block_group() returns block group X; 2) Block group X is in the unused block groups discard list (its discard index is BTRFS_DISCARD_INDEX_UNUSED) since at some point in the past it become an unused block group and was added to that list, but then later it got an extent allocated from it, so its ->used counter is not zero anymore; 3) The current transaction is aborted by task B and we end up at __btrfs_handle_fs_error() in the transaction abort path, where we call btrfs_discard_stop(), which clears BTRFS_FS_DISCARD_RUNNING from fs_info, and then at __btrfs_handle_fs_error() we set the fs to RO mode (setting SB_RDONLY in the super block's s_flags field); 4) Task A calls __add_to_discard_list() with the goal of moving the block group from the unused block groups discard list into another discard list, but at __add_to_discard_list() we end up doing nothing because btrfs_run_discard_work() returns false, since the super block has SB_RDONLY set in its flags and BTRFS_FS_DISCARD_RUNNING is not set anymore in fs_info->flags. So block group X remains in the unused block groups discard list; 5) Task A then does a goto into the 'again' label, calls find_next_block_group() again we gets block group X again. Then it repeats the previous steps over and over since there are not other block groups in the discard lists and block group X is never moved out of the unused block groups discard list since btrfs_run_discard_work() keeps returning false and therefore __add_to_discard_list() doesn't move block group X out of that discard list. When this happens we can get a soft lockup report like this: [71.957] watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:3:97] [71.957] Modules linked in: xfs af_packet rfkill (...) [71.957] CPU: 0 UID: 0 PID: 97 Comm: kworker/u4:3 Tainted: G W 6.14.2-1-default #1 openSUSE Tumbleweed 968795ef2b1407352128b466fe887416c33af6fa [71.957] Tainted: [W]=WARN [71.957] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 [71.957] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [71.957] RIP: 0010:btrfs_discard_workfn+0xc4/0x400 [btrfs] [71.957] Code: c1 01 48 83 (...) [71.957] RSP: 0018:ffffafaec03efe08 EFLAGS: 00000246 [71.957] RAX: ffff897045500000 RBX: ffff8970413ed8d0 RCX: 0000000000000000 [71.957] RDX: 0000000000000001 RSI: ffff8970413ed8d0 RDI: 0000000a8f1272ad [71.957] RBP: 0000000a9d61c60e R08: ffff897045500140 R09: 8080808080808080 [71.957] R10: ffff897040276800 R11: fefefefefefefeff R12: ffff8970413ed860 [71.957] R13: ffff897045500000 R14: ffff8970413ed868 R15: 0000000000000000 [71.957] FS: 0000000000000000(0000) GS:ffff89707bc00000(0000) knlGS:0000000000000000 [71.957] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [71.957] CR2: 00005605bcc8d2f0 CR3: 000000010376a001 CR4: 0000000000770ef0 [71.957] PKRU: 55555554 [71.957] Call Trace: [71.957] [71.957] process_one_work+0x17e/0x330 [71.957] worker_thread+0x2ce/0x3f0 [71.957] ? __pfx_worker_thread+0x10/0x10 [71.957] kthread+0xef/0x220 [71.957] ? __pfx_kthread+0x10/0x10 [71.957] ret_from_fork+0x34/0x50 [71.957] ? __pfx_kthread+0x10/0x10 [71.957] ret_from_fork_asm+0x1a/0x30 [71.957] [71.957] Kernel panic - not syncing: softlockup: hung tasks [71.987] CPU: 0 UID: 0 PID: 97 Comm: kworker/u4:3 Tainted: G W L 6.14.2-1-default #1 openSUSE Tumbleweed 968795ef2b1407352128b466fe887416c33af6fa [71.989] Tainted: [W]=WARN, [L]=SOFTLOCKUP [71.989] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 [71.991] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [71.992] Call Trace: [71.993] [71.994] dump_stack_lvl+0x5a/0x80 [71.994] panic+0x10b/0x2da [71.995] watchdog_timer_fn.cold+0x9a/0xa1 [71.996] ? __pfx_watchdog_timer_fn+0x10/0x10 [71.997] __hrtimer_run_queues+0x132/0x2a0 [71.997] hrtimer_interrupt+0xff/0x230 [71.998] __sysvec_apic_timer_interrupt+0x55/0x100 [71.999] sysvec_apic_timer_interrupt+0x6c/0x90 [72.000] [72.000] [72.001] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [72.002] RIP: 0010:btrfs_discard_workfn+0xc4/0x400 [btrfs] [72.002] Code: c1 01 48 83 (...) [72.005] RSP: 0018:ffffafaec03efe08 EFLAGS: 00000246 [72.006] RAX: ffff897045500000 RBX: ffff8970413ed8d0 RCX: 0000000000000000 [72.006] RDX: 0000000000000001 RSI: ffff8970413ed8d0 RDI: 0000000a8f1272ad [72.007] RBP: 0000000a9d61c60e R08: ffff897045500140 R09: 8080808080808080 [72.008] R10: ffff897040276800 R11: fefefefefefefeff R12: ffff8970413ed860 [72.009] R13: ffff897045500000 R14: ffff8970413ed868 R15: 0000000000000000 [72.010] ? btrfs_discard_workfn+0x51/0x400 [btrfs 23b01089228eb964071fb7ca156eee8cd3bf996f] [72.011] process_one_work+0x17e/0x330 [72.012] worker_thread+0x2ce/0x3f0 [72.013] ? __pfx_worker_thread+0x10/0x10 [72.014] kthread+0xef/0x220 [72.014] ? __pfx_kthread+0x10/0x10 [72.015] ret_from_fork+0x34/0x50 [72.015] ? __pfx_kthread+0x10/0x10 [72.016] ret_from_fork_asm+0x1a/0x30 [72.017] [72.017] Kernel Offset: 0x15000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [72.019] Rebooting in 90 seconds.. So fix this by making sure we move a block group out of the unused block groups discard list when calling __add_to_discard_list(). Fixes: 2bee7eb8bb81 ("btrfs: discard one region at a time in async discard") Link: https://bugzilla.suse.com/show_bug.cgi?id=1242012 CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Boris Burkov Reviewed-by: Daniel Vacek Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 12f69c4e309845ad2823b3a095019526a529578f Author: Tiezhu Yang Date: Wed May 14 22:18:10 2025 +0800 LoongArch: uprobes: Remove redundant code about resume_era commit 12614f794274f63fbdfe76771b2b332077d63848 upstream. arch_uprobe_skip_sstep() returns true if instruction was emulated, that is to say, there is no need to single step for the emulated instructions. regs->csr_era will point to the destination address directly after the exception, so the resume_era related code is redundant, just remove them. Cc: stable@vger.kernel.org Fixes: 19bc6cb64092 ("LoongArch: Add uprobes support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 88650dde2eeaf157eddf55cdc5d47d46f691c905 Author: Tiezhu Yang Date: Wed May 14 22:18:10 2025 +0800 LoongArch: uprobes: Remove user_{en,dis}able_single_step() commit 0b326b2371f94e798137cc1a3c5c2eef2bc69061 upstream. When executing the "perf probe" and "perf stat" test cases about some cryptographic algorithm, the output shows that "Trace/breakpoint trap". This is because it uses the software singlestep breakpoint for uprobes on LoongArch, and no need to use the hardware singlestep. So just remove the related function call to user_{en,dis}able_single_step() for uprobes on LoongArch. How to reproduce: Please make sure CONFIG_UPROBE_EVENTS is set and openssl supports sm2 algorithm, then execute the following command. cd tools/perf && make ./perf probe -x /usr/lib64/libcrypto.so BN_mod_mul_montgomery ./perf stat -e probe_libcrypto:BN_mod_mul_montgomery openssl speed sm2 Cc: stable@vger.kernel.org Fixes: 19bc6cb64092 ("LoongArch: Add uprobes support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c92b99c4c0977c4e935a24918310f1fb8311b178 Author: Huacai Chen Date: Wed May 14 22:17:43 2025 +0800 LoongArch: Fix MAX_REG_OFFSET calculation commit 90436d234230e9a950ccd87831108b688b27a234 upstream. Fix MAX_REG_OFFSET calculation, make it point to the last register in 'struct pt_regs' and not to the marker itself, which could allow regs_get_register() to return an invalid offset. Cc: stable@vger.kernel.org Fixes: 803b0fc5c3f2baa6e5 ("LoongArch: Add process management") Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 2135336574354e1de870015e2b39b5b793f131cb Author: Huacai Chen Date: Wed May 14 22:17:52 2025 +0800 LoongArch: Save and restore CSR.CNTC for hibernation commit ceb9155d058a11242aa0572875c44e9713b1a2be upstream. Save and restore CSR.CNTC for hibernation which is similar to suspend. For host this is unnecessary because sched clock is ensured continuous, but for kvm guest sched clock isn't enough because rdtime.d should also be continuous. Host::rdtime.d = Host::CSR.CNTC + counter Guest::rdtime.d = Host::CSR.CNTC + Host::CSR.GCNTC + Guest::CSR.CNTC + counter so, Guest::rdtime.d = Host::rdtime.d + Host::CSR.GCNTC + Guest::CSR.CNTC To ensure Guest::rdtime.d continuous, Host::rdtime.d should be at first continuous, while Host::CSR.GCNTC / Guest::CSR.CNTC is maintained by KVM. Cc: stable@vger.kernel.org Signed-off-by: Xianglai Li Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 66a309b4d5bdbe59b53957246fe87af1c95a6691 Author: Huacai Chen Date: Wed May 14 22:17:52 2025 +0800 LoongArch: Move __arch_cpu_idle() to .cpuidle.text section commit 3e245b7b74c3a2ead5fa4bad27cc275284c75189 upstream. Now arch_cpu_idle() is annotated with __cpuidle which means it is in the .cpuidle.text section, but __arch_cpu_idle() isn't. Thus, fix the missing .cpuidle.text section assignment for __arch_cpu_idle() in order to correct backtracing with nmi_backtrace(). The principle is similar to the commit 97c8580e85cf81c ("MIPS: Annotate cpu_wait implementations with __cpuidle") Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 111e55db3ca360a76e63e8a94208eccdacca48f0 Author: Tianyang Zhang Date: Wed May 14 22:17:43 2025 +0800 LoongArch: Prevent cond_resched() occurring within kernel-fpu commit 2468b0e3d5659dfde77f081f266e1111a981efb8 upstream. When CONFIG_PREEMPT_COUNT is not configured (i.e. CONFIG_PREEMPT_NONE/ CONFIG_PREEMPT_VOLUNTARY), preempt_disable() / preempt_enable() merely acts as a barrier(). However, in these cases cond_resched() can still trigger a context switch and modify the CSR.EUEN, resulting in do_fpu() exception being activated within the kernel-fpu critical sections, as demonstrated in the following path: dcn32_calculate_wm_and_dlg() DC_FP_START() dcn32_calculate_wm_and_dlg_fpu() dcn32_find_dummy_latency_index_for_fw_based_mclk_switch() dcn32_internal_validate_bw() dcn32_enable_phantom_stream() dc_create_stream_for_sink() kzalloc(GFP_KERNEL) __kmem_cache_alloc_node() __cond_resched() DC_FP_END() This patch is similar to commit d02198550423a0b (x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs). It uses local_bh_disable() instead of preempt_disable() for non-RT kernels so it can avoid the cond_resched() issue, and also extend the kernel-fpu application scenarios to the softirq context. Cc: stable@vger.kernel.org Signed-off-by: Tianyang Zhang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit f8544be7e8e55b0ef23e1ab90e23e8d4d4aad3d3 Author: Rong Zhang Date: Mon May 12 23:24:19 2025 +0800 HID: bpf: abort dispatch if device destroyed commit 578e1b96fad7402ff7e9c7648c8f1ad0225147c8 upstream. The current HID bpf implementation assumes no output report/request will go through it after hid_bpf_destroy_device() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages. The bug will be triggered if the conditions below are met: A) a device under the driver has some LEDs on B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver) If condition A is met, hidinput_led_worker() is always scheduled *after* hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] This is fine when condition B is not met, where hidinput_led_worker() calls hid_ll_driver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request. Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads to the bug. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also exists in dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinput_led_worker() falls back to hid_hw_raw_request() when hid_ll_driver->output_report() is uninplemented (e.g., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Fix the issue by returning early in the two mentioned functions if hid_bpf has been marked as destroyed. Though dispatch_hid_bpf_device_event() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions. The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report") Closes: https://lore.kernel.org/all/20250506145548.GGaBoi9Jzp3aeJizTR@fat_crate.local/ Fixes: 8bd0488b5ea5 ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Tested-by: Petr Tesarik Link: https://patch.msgid.link/20250512152420.87441-1-i@rong.moe Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit d32c1880b33afd2df39f9155da5d52a4ea91110e Author: Jan Kara Date: Wed May 7 11:49:41 2025 +0200 udf: Make sure i_lenExtents is uptodate on inode eviction commit 55dd5b4db3bf04cf077a8d1712f6295d4517c337 upstream. UDF maintains total length of all extents in i_lenExtents. Generally we keep extent lengths (and thus i_lenExtents) block aligned because it makes the file appending logic simpler. However the standard mandates that the inode size must match the length of all extents and thus we trim the last extent when closing the file. To catch possible bugs we also verify that i_lenExtents matches i_size when evicting inode from memory. Commit b405c1e58b73 ("udf: refactor udf_next_aext() to handle error") however broke the code updating i_lenExtents and thus udf_evict_inode() ended up spewing lots of errors about incorrectly sized extents although the extents were actually sized properly. Fix the updating of i_lenExtents to silence the errors. Fixes: b405c1e58b73 ("udf: refactor udf_next_aext() to handle error") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 0102989af4c334d1d98b2a0fd4d61a5152e39b72 Author: Tejun Heo Date: Mon May 5 11:30:39 2025 -1000 sched_ext: bpf_iter_scx_dsq_new() should always initialize iterator commit 428dc9fc0873989d73918d4a9cc22745b7bbc799 upstream. BPF programs may call next() and destroy() on BPF iterators even after new() returns an error value (e.g. bpf_for_each() macro ignores error returns from new()). bpf_iter_scx_dsq_new() could leave the iterator in an uninitialized state after an error return causing bpf_iter_scx_dsq_next() to dereference garbage data. Make bpf_iter_scx_dsq_new() always clear $kit->dsq so that next() and destroy() become noops. Signed-off-by: Tejun Heo Fixes: 650ba21b131e ("sched_ext: Implement DSQ iterator") Cc: stable@vger.kernel.org # v6.12+ Acked-by: Andrea Righi Signed-off-by: Greg Kroah-Hartman commit a0c2478218136616e1ebc3c544bdc94988a9ac5f Author: Nathan Lynch Date: Thu Apr 3 11:24:19 2025 -0500 dmaengine: Revert "dmaengine: dmatest: Fix dmatest waiting less when interrupted" commit df180e65305f8c1e020d54bfc2132349fd693de1 upstream. Several issues with this change: * The analysis is flawed and it's unclear what problem is being fixed. There is no difference between wait_event_freezable_timeout() and wait_event_timeout() with respect to device interrupts. And of course "the interrupt notifying the finish of an operation happens during wait_event_freezable_timeout()" -- that's how it's supposed to work. * The link at the "Closes:" tag appears to be an unrelated use-after-free in idxd. * It introduces a regression: dmatest threads are meant to be freezable and this change breaks that. See discussion here: https://lore.kernel.org/dmaengine/878qpa13fe.fsf@AUSNATLYNCH.amd.com/ Fixes: e87ca16e9911 ("dmaengine: dmatest: Fix dmatest waiting less when interrupted") Signed-off-by: Nathan Lynch Link: https://lore.kernel.org/r/20250403-dmaengine-dmatest-revert-waiting-less-v1-1-8227c5a3d7c8@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 153367726797aaf56a70782214784f9f1ca7e945 Author: Trond Myklebust Date: Sat May 10 10:50:13 2025 -0400 NFSv4/pnfs: Reset the layout state after a layoutreturn [ Upstream commit 6d6d7f91cc8c111d40416ac9240a3bb9396c5235 ] If there are still layout segments in the layout plh_return_lsegs list after a layout return, we should be resetting the state to ensure they eventually get returned as well. Fixes: 68f744797edd ("pNFS: Do not free layout segments that are marked for return") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 6dbf38159d8d4f8009b806b71954daf0a854cb92 Author: Gerhard Engleder Date: Wed May 14 21:56:57 2025 +0200 tsnep: fix timestamping with a stacked DSA driver [ Upstream commit b3ca9eef6646576ad506a96d941d87a69f66732a ] This driver is susceptible to a form of the bug explained in commit c26a2c2ddc01 ("gianfar: Fix TX timestamping with a stacked DSA driver") and in Documentation/networking/timestamping.rst section "Other caveats for MAC drivers", specifically it timestamps any skb which has SKBTX_HW_TSTAMP, and does not consider if timestamping has been enabled in adapter->hwtstamp_config.tx_type. Evaluate the proper TX timestamping condition only once on the TX path (in tsnep_xmit_frame_ring()) and store the result in an additional TX entry flag. Evaluate the new TX entry flag in the TX confirmation path (in tsnep_tx_poll()). This way SKBTX_IN_PROGRESS is set by the driver as required, but never evaluated. SKBTX_IN_PROGRESS shall not be evaluated as it can be set by a stacked DSA driver and evaluating it would lead to unwanted timestamps. Fixes: 403f69bbdbad ("tsnep: Add TSN endpoint Ethernet MAC driver") Suggested-by: Vladimir Oltean Signed-off-by: Gerhard Engleder Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250514195657.25874-1-gerhard@engleder-embedded.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a11b8c0be6acd0505a58ff40d474bd778b25b93a Author: Pengtao He Date: Wed May 14 21:20:13 2025 +0800 net/tls: fix kernel panic when alloc_page failed [ Upstream commit 491deb9b8c4ad12fe51d554a69b8165b9ef9429f ] We cannot set frag_list to NULL pointer when alloc_page failed. It will be used in tls_strp_check_queue_ok when the next time tls_strp_read_sock is called. This is because we don't reset full_len in tls_strp_flush_anchor_copy() so the recv path will try to continue handling the partial record on the next call but we dettached the rcvq from the frag list. Alternative fix would be to reset full_len. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Call trace: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798 Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Signed-off-by: Pengtao He Link: https://patch.msgid.link/20250514132013.17274-1-hept.hept.hept@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abc43c1ffdbc801b0b04ac845bfaf1d42b8f68f7 Author: Ido Schimmel Date: Wed May 14 14:48:05 2025 +0200 mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices [ Upstream commit 92ec4855034b2c4d13f117558dc73d20581fa9ff ] The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices: # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP (Note that the neighbor is not marked with 'offload') When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one: # devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted: # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1 Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 8fdb09a7674c ("mlxsw: spectrum_router: Replay neighbours when RIF is made") Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Signed-off-by: Petr Machata Link: https://patch.msgid.link/c53c02c904fde32dad484657be3b1477884e9ad6.1747225701.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07c737d9ab02c07b562aefcca16aa95077368e24 Author: Kees Cook Date: Fri May 9 11:46:45 2025 -0700 wifi: mac80211: Set n_channels after allocating struct cfg80211_scan_request [ Upstream commit 82bbe02b2500ef0a62053fe2eb84773fe31c5a0a ] Make sure that n_channels is set after allocating the struct cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions because I failed to locate the allocation likely due to the "sizeof(void *)" not matching the "channels" array type. Reported-by: syzbot+4bcdddd48bb6f0be0da1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/680fd171.050a0220.2b69d1.045e.GAE@google.com/ Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/20250509184641.work.542-kees@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7db81acae0842bd19631fb69152592837a1d250f Author: Subbaraya Sundeep Date: Mon May 12 18:22:37 2025 +0530 octeontx2-pf: Do not reallocate all ntuple filters [ Upstream commit dcb479fde00be9a151c047d0a7c0626b64eb0019 ] If ntuple filters count is modified followed by unicast filters count using devlink then the ntuple count set by user is ignored and all the ntuple filters are being reallocated. Fix this by storing the ntuple count set by user. Without this patch, say if user tries to modify ntuple count as 8 followed by ucast filter count as 4 using devlink commands then ntuple count is being reverted to default value 16 i.e, not retaining user set value 8. Fixes: 39c469188b6d ("octeontx2-pf: Add ucast filter count configurability via devlink.") Signed-off-by: Subbaraya Sundeep Reviewed-by: Simon Horman Link: https://patch.msgid.link/1747054357-5850-1-git-send-email-sbhatta@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1977cec5beaaa84363a933f17c35eb61d67ce7cc Author: Hariprasad Kelam Date: Tue May 13 12:45:54 2025 +0530 octeontx2-af: Fix CGX Receive counters [ Upstream commit bf449f35e77fd44017abf991fac1f9ab7705bbe0 ] Each CGX block supports 4 logical MACs (LMACS). Receive counters CGX_CMR_RX_STAT0-8 are per LMAC and CGX_CMR_RX_STAT9-12 are per CGX. Due a bug in previous patch, stale Per CGX counters values observed. Fixes: 66208910e57a ("octeontx2-af: Support to retrieve CGX LMAC stats") Signed-off-by: Hariprasad Kelam Link: https://patch.msgid.link/20250513071554.728922-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 256adb2da5839e72df8d409556b27180cfae9583 Author: Bo-Cun Chen Date: Tue May 13 05:27:30 2025 +0100 net: ethernet: mtk_eth_soc: fix typo for declaration MT7988 ESW capability [ Upstream commit 1bdea6fad6fb985ff13828373c48e337c4e939f9 ] Since MTK_ESW_BIT is a bit number rather than a bitmap, it causes MTK_HAS_CAPS to produce incorrect results. This leads to the ETH driver not declaring MAC capabilities correctly for the MT7988 ESW. Fixes: 445eb6448ed3 ("net: ethernet: mtk_eth_soc: add basic support for MT7988 SoC") Signed-off-by: Bo-Cun Chen Signed-off-by: Daniel Golle Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/b8b37f409d1280fad9c4d32521e6207f63cd3213.1747110258.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf85a27605d09495a9d476c50d5121ba6c2dad88 Author: Subbaraya Sundeep Date: Mon May 12 18:12:36 2025 +0530 octeontx2-pf: macsec: Fix incorrect max transmit size in TX secy [ Upstream commit 865ab2461375e3a5a2526f91f9a9f17b8931bc9e ] MASCEC hardware block has a field called maximum transmit size for TX secy. Max packet size going out of MCS block has be programmed taking into account full packet size which has L2 header,SecTag and ICV. MACSEC offload driver is configuring max transmit size as macsec interface MTU which is incorrect. Say with 1500 MTU of real device, macsec interface created on top of real device will have MTU of 1468(1500 - (SecTag + ICV)). This is causing packets from macsec interface of size greater than or equal to 1468 are not getting transmitted out because driver programmed max transmit size as 1468 instead of 1514(1500 + ETH_HDR_LEN). Fixes: c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading") Signed-off-by: Subbaraya Sundeep Reviewed-by: Simon Horman Link: https://patch.msgid.link/1747053756-4529-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38a2fdd3e9c9730db1d394771b3c0015357ab535 Author: Jakub Kicinski Date: Tue May 13 15:16:38 2025 -0700 netlink: specs: tc: all actions are indexed arrays [ Upstream commit f3dd5fb2fa494dcbdb10f8d27f2deac8ef61a2fc ] Some TC filters have actions listed as indexed arrays of nests and some as just nests. They are all indexed arrays, the handling is common across filters. Fixes: 2267672a6190 ("doc/netlink/specs: Update the tc spec") Link: https://patch.msgid.link/20250513221638.842532-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit be64ab9c173f41aa84e6b8d76dbda95fe1d8bd24 Author: Jakub Kicinski Date: Tue May 13 15:13:16 2025 -0700 netlink: specs: tc: fix a couple of attribute names [ Upstream commit a9fb87b8b86918e34ef6bf3316311f41bc1a5b1f ] Fix up spelling of two attribute names. These are clearly typoes and will prevent C codegen from working. Let's treat this as a fix to get the correction into users' hands ASAP, and prevent anyone depending on the wrong names. Fixes: a1bcfde83669 ("doc/netlink/specs: Add a spec for tc") Link: https://patch.msgid.link/20250513221316.841700-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3f16340071d0664c3937e87963d11920dd11ed74 Author: Umesh Nerlige Ramappa Date: Fri May 9 09:12:01 2025 -0700 drm/xe: Save CTX_TIMESTAMP mmio value instead of LRC value [ Upstream commit 66c8f7b435bddb7d8577ac8a57e175a6cb147227 ] For determining actual job execution time, save the current value of the CTX_TIMESTAMP register rather than the value saved in LRC since the current register value is the closest to the start time of the job. v2: Define MI_STORE_REGISTER_MEM to fix compile error v3: Place MI_STORE_REGISTER_MEM sorted by MI_INSTR (Lucas) Fixes: 65921374c48f ("drm/xe: Emit ctx timestamp copy in ring ops") Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Matthew Brost Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250509161159.2173069-6-umesh.nerlige.ramappa@intel.com (cherry picked from commit 38b14233e5deff51db8faec287b4acd227152246) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit d2a9a92bb4cc7568cff68241b0051dc7268bdc68 Author: Cosmin Tanislav Date: Thu May 8 09:49:43 2025 +0300 regulator: max20086: fix invalid memory access [ Upstream commit 6b0cd72757c69bc2d45da42b41023e288d02e772 ] max20086_parse_regulators_dt() calls of_regulator_match() using an array of struct of_regulator_match allocated on the stack for the matches argument. of_regulator_match() calls devm_of_regulator_put_matches(), which calls devres_alloc() to allocate a struct devm_of_regulator_matches which will be de-allocated using devm_of_regulator_put_matches(). struct devm_of_regulator_matches is populated with the stack allocated matches array. If the device fails to probe, devm_of_regulator_put_matches() will be called and will try to call of_node_put() on that stack pointer, generating the following dmesg entries: max20086 6-0028: Failed to read DEVICE_ID reg: -121 kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet kobject_put() is being called. Followed by a stack trace matching the call flow described above. Switch to allocating the matches array using devm_kcalloc() to avoid accessing the stack pointer long after it's out of scope. This also has the advantage of allowing multiple max20086 to probe without overriding the data stored inside the global of_regulator_match. Fixes: bfff546aae50 ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by: Cosmin Tanislav Link: https://patch.msgid.link/20250508064947.2567255-1-demonsingur@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5451b834b3ff21a7d79610b560d0598679d994e9 Author: Abdun Nihaal Date: Mon May 12 10:18:27 2025 +0530 qlcnic: fix memory leak in qlcnic_sriov_channel_cfg_cmd() [ Upstream commit 9d8a99c5a7c7f4f7eca2c168a4ec254409670035 ] In one of the error paths in qlcnic_sriov_channel_cfg_cmd(), the memory allocated in qlcnic_sriov_alloc_bc_mbx_args() for mailbox arguments is not freed. Fix that by jumping to the error path that frees them, by calling qlcnic_free_mbx_args(). This was found using static analysis. Fixes: f197a7aa6288 ("qlcnic: VF-PF communication channel implementation") Signed-off-by: Abdun Nihaal Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250512044829.36400-1-abdun.nihaal@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f80e6ff026041721d8089da8c269b1963628325 Author: Carolina Jubran Date: Sun May 11 13:15:52 2025 +0300 net/mlx5e: Disable MACsec offload for uplink representor profile [ Upstream commit 588431474eb7572e57a927fa8558c9ba2f8af143 ] MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features. If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set. Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features(). Kernel log: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sendmsg+0xeb/0x170 ? kasan_save_stack+0x30/0x40 ? copy_msghdr_from_user+0x110/0x110 ? do_syscall_64+0x6d/0x140 ? lock_acquire+0x1c2/0x530 ? __virt_addr_valid+0x116/0x3b0 ? __virt_addr_valid+0x1da/0x3b0 ? lock_downgrade+0x680/0x680 ? __delete_object+0x21/0x50 __sys_sendmsg+0xf7/0x180 ? __sys_sendmsg_sock+0x20/0x20 ? kmem_cache_free+0x14c/0x4e0 ? __x64_sys_close+0x78/0xd0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f855e113367 Code: 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007ffd15e90c88 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f855e113367 RDX: 0000000000000000 RSI: 00007ffd15e90cf0 RDI: 0000000000000004 RBP: 00007ffd15e90dbc R08: 0000000000000028 R09: 000000000045d100 R10: 00007f855e011dd8 R11: 0000000000000246 R12: 0000000000000019 R13: 0000000067c6b785 R14: 00000000004a1e80 R15: 0000000000000000 Modules linked in: 8021q garp mrp sch_ingress openvswitch nsh mlx5_ib mlx5_fwctl mlx5_dpll mlx5_core rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: mlx5_core] ---[ end trace 0000000000000000 ]--- Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Signed-off-by: Carolina Jubran Reviewed-by: Shahar Shitrit Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/1746958552-561295-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 462e2243812e7bdcfa3c23a621aca5d62004d2d7 Author: Konstantin Shkolnyy Date: Wed May 7 10:14:56 2025 -0500 vsock/test: Fix occasional failure in SIOCOUTQ tests [ Upstream commit 7fd7ad6f36af36f30a06d165eff3780cb139fa79 ] These tests: "SOCK_STREAM ioctl(SIOCOUTQ) 0 unsent bytes" "SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes" output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)". They test that the SIOCOUTQ ioctl reports 0 unsent bytes after the data have been received by the other side. However, sometimes there is a delay in updating this "unsent bytes" counter, and the test fails even though the counter properly goes to 0 several milliseconds later. The delay occurs in the kernel because the used buffer notification callback virtio_vsock_tx_done(), called upon receipt of the data by the other side, doesn't update the counter itself. It delegates that to a kernel thread (via vsock->tx_work). Sometimes that thread is delayed more than the test expects. Change the test to poll SIOCOUTQ until it returns 0 or a timeout occurs. Signed-off-by: Konstantin Shkolnyy Reviewed-by: Stefano Garzarella Fixes: 18ee44ce97c1 ("test/vsock: add ioctl unsent bytes test") Link: https://patch.msgid.link/20250507151456.2577061-1-kshk@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 225e29465aa78f6b68ae8d3848cdd879a958c969 Author: Jonas Gorski Date: Thu May 8 11:14:24 2025 +0200 net: dsa: b53: prevent standalone from trying to forward to other ports [ Upstream commit 4227ea91e2657f7965e34313448e9d0a2b67712e ] When bridged ports and standalone ports share a VLAN, e.g. via VLAN uppers, or untagged traffic with a vlan unaware bridge, the ASIC will still try to forward traffic to known FDB entries on standalone ports. But since the port VLAN masks prevent forwarding to bridged ports, this traffic will be dropped. This e.g. can be observed in the bridge_vlan_unaware ping tests, where this breaks pinging with learning on. Work around this by enabling the simplified EAP mode on switches supporting it for standalone ports, which causes the ASIC to redirect traffic of unknown source MAC addresses to the CPU port. Since standalone ports do not learn, there are no known source MAC addresses, so effectively this redirects all incoming traffic to the CPU port. Fixes: ff39c2d68679 ("net: dsa: b53: Add bridge support") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250508091424.26870-1-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bd993721789d0d7716d1413bdf7c6f8562263ecb Author: Geert Uytterhoeven Date: Tue May 13 09:31:04 2025 +0200 ALSA: sh: SND_AICA should depend on SH_DMA_API [ Upstream commit 66e48ef6ef506c89ec1b3851c6f9f5f80b5835ff ] If CONFIG_SH_DMA_API=n: WARNING: unmet direct dependencies detected for G2_DMA Depends on [n]: SH_DREAMCAST [=y] && SH_DMA_API [=n] Selected by [y]: - SND_AICA [=y] && SOUND [=y] && SND [=y] && SND_SUPERH [=y] && SH_DREAMCAST [=y] SND_AICA selects G2_DMA. As the latter depends on SH_DMA_API, the former should depend on SH_DMA_API, too. Fixes: f477a538c14d07f8 ("sh: dma: fix kconfig dependency for G2_DMA") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505131320.PzgTtl9H-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/b90625f8a9078d0d304bafe862cbe3a3fab40082.1747121335.git.geert+renesas@glider.be Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a3c147040bb25e267daf9deab611daff629c7ccf Author: Keith Busch Date: Thu May 8 16:57:06 2025 +0200 nvme-pci: acquire cq_poll_lock in nvme_poll_irqdisable [ Upstream commit 3d8932133dcecbd9bef1559533c1089601006f45 ] We need to lock this queue for that condition because the timeout work executes per-namespace and can poll the poll CQ. Reported-by: Hannes Reinecke Closes: https://lore.kernel.org/all/20240902130728.1999-1-hare@kernel.org/ Fixes: a0fa9647a54e ("NVMe: add blk polling support") Signed-off-by: Keith Busch Signed-off-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ddfa034da3188825d0234f810681a18f1d443c1b Author: Kees Cook Date: Tue May 6 20:35:40 2025 -0700 nvme-pci: make nvme_pci_npages_prp() __always_inline [ Upstream commit 40696426b8c8c4f13cf6ac52f0470eed144be4b2 ] The only reason nvme_pci_npages_prp() could be used as a compile-time known result in BUILD_BUG_ON() is because the compiler was always choosing to inline the function. Under special circumstances (sanitizer coverage functions disabled for __init functions on ARCH=um), the compiler decided to stop inlining it: drivers/nvme/host/pci.c: In function 'nvme_init': include/linux/compiler_types.h:557:45: error: call to '__compiletime_assert_678' declared with attribute error: BUILD_BUG_ON failed: nvme_pci_npages_prp() > NVME_MAX_NR_ALLOCATIONS 557 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:538:25: note: in definition of macro '__compiletime_assert' 538 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:557:9: note: in expansion of macro '_compiletime_assert' 557 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~~~~~~~~~~~~~ drivers/nvme/host/pci.c:3804:9: note: in expansion of macro 'BUILD_BUG_ON' 3804 | BUILD_BUG_ON(nvme_pci_npages_prp() > NVME_MAX_NR_ALLOCATIONS); | ^~~~~~~~~~~~ Force it to be __always_inline to make sure it is always available for use with BUILD_BUG_ON(). Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505061846.12FMyRjj-lkp@intel.com/ Fixes: c372cdd1efdf ("nvme-pci: iod npages fits in s8") Signed-off-by: Kees Cook Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 0251e13f3f49e2b68b575dfaa7113ec110f25043 Author: Vladimir Oltean Date: Fri May 9 14:38:16 2025 +0300 net: dsa: sja1105: discard incoming frames in BR_STATE_LISTENING [ Upstream commit 498625a8ab2c8e1c9ab5105744310e8d6952cc01 ] It has been reported that when under a bridge with stp_state=1, the logs get spammed with this message: [ 251.734607] fsl_dpaa2_eth dpni.5 eth0: Couldn't decode source port Further debugging shows the following info associated with packets: source_port=-1, switch_id=-1, vid=-1, vbid=1 In other words, they are data plane packets which are supposed to be decoded by dsa_tag_8021q_find_port_by_vbid(), but the latter (correctly) refuses to do so, because no switch port is currently in BR_STATE_LEARNING or BR_STATE_FORWARDING - so the packet is effectively unexpected. The error goes away after the port progresses to BR_STATE_LEARNING in 15 seconds (the default forward_time of the bridge), because then, dsa_tag_8021q_find_port_by_vbid() can correctly associate the data plane packets with a plausible bridge port in a plausible STP state. Re-reading IEEE 802.1D-1990, I see the following: "4.4.2 Learning: (...) The Forwarding Process shall discard received frames." IEEE 802.1D-2004 further clarifies: "DISABLED, BLOCKING, LISTENING, and BROKEN all correspond to the DISCARDING port state. While those dot1dStpPortStates serve to distinguish reasons for discarding frames, the operation of the Forwarding and Learning processes is the same for all of them. (...) LISTENING represents a port that the spanning tree algorithm has selected to be part of the active topology (computing a Root Port or Designated Port role) but is temporarily discarding frames to guard against loops or incorrect learning." Well, this is not what the driver does - instead it sets mac[port].ingress = true. To get rid of the log spam, prevent unexpected data plane packets to be received by software by discarding them on ingress in the LISTENING state. In terms of blame attribution: the prints only date back to commit d7f9787a763f ("net: dsa: tag_8021q: add support for imprecise RX based on the VBID"). However, the settings would permit a LISTENING port to forward to a FORWARDING port, and the standard suggests that's not OK. Fixes: 640f763f98c2 ("net: dsa: sja1105: Add support for Spanning Tree Protocol") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250509113816.2221992-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e64d35475aa21d13dab71da51de51923c1a3a48 Author: Mathieu Othacehe Date: Fri May 9 14:19:35 2025 +0200 net: cadence: macb: Fix a possible deadlock in macb_halt_tx. [ Upstream commit c92d6089d8ad7d4d815ebcedee3f3907b539ff1f ] There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore. Fixes: e86cd53afc590 ("net/macb: better manage tx errors") Signed-off-by: Mathieu Othacehe Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250509121935.16282-1-othacehe@gnu.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ee626e47330035bbf3d2df428ccfdd00b8bfd1b Author: Takashi Iwai Date: Sun May 11 16:11:45 2025 +0200 ALSA: ump: Fix a typo of snd_ump_stream_msg_device_info [ Upstream commit dd33993a9721ab1dae38bd37c9f665987d554239 ] s/devince/device/ It's used only internally, so no any behavior changes. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Acked-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20250511141147.10246-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit caac5761a6cd801a9754e9bb1487b4deb9930344 Author: Takashi Iwai Date: Sun May 11 15:45:27 2025 +0200 ALSA: seq: Fix delivery of UMP events to group ports [ Upstream commit ff7b190aef6cccdb6f14d20c5753081fe6420e0b ] When an event with UMP message is sent to a UMP client, the EP port receives always no matter where the event is sent to, as it's a catch-all port. OTOH, if an event is sent to EP port, and if the event has a certain UMP Group, it should have been delivered to the associated UMP Group port, too, but this was ignored, so far. This patch addresses the behavior. Now a UMP event sent to the Endpoint port will be delivered to the subscribers of the UMP group port the event is associated with. The patch also does a bit of refactoring to simplify the code about __deliver_to_subscribers(). Fixes: 177ccf811df4 ("ALSA: seq: Support MIDI 2.0 UMP Endpoint port") Link: https://patch.msgid.link/20250511134528.6314-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8ee6ec20dd5fb29970f00653e2daebfe6f956dd3 Author: Andrew Jeffery Date: Thu May 8 14:16:00 2025 +0930 net: mctp: Ensure keys maintain only one ref to corresponding dev [ Upstream commit e4f349bd6e58051df698b82f94721f18a02a293d ] mctp_flow_prepare_output() is called in mctp_route_output(), which places outbound packets onto a given interface. The packet may represent a message fragment, in which case we provoke an unbalanced reference count to the underlying device. This causes trouble if we ever attempt to remove the interface: [ 48.702195] usb 1-1: USB disconnect, device number 2 [ 58.883056] unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2 [ 69.022548] unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2 [ 79.172568] unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2 ... Predicate the invocation of mctp_dev_set_key() in mctp_flow_prepare_output() on not already having associated the device with the key. It's not yet realistic to uphold the property that the key maintains only one device reference earlier in the transmission sequence as the route (and therefore the device) may not be known at the time the key is associated with the socket. Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers") Acked-by: Jeremy Kerr Signed-off-by: Andrew Jeffery Link: https://patch.msgid.link/20250508-mctp-dev-refcount-v1-1-d4f965c67bb5@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d308312acd0cbbf40b97a018eff5659b09660fae Author: Cosmin Ratiu Date: Thu May 8 11:44:34 2025 +0300 tests/ncdevmem: Fix double-free of queue array [ Upstream commit 97c4e094a4b2edbb4fffeda718f8e806f825a18f ] netdev_bind_rx takes ownership of the queue array passed as parameter and frees it, so a queue array buffer cannot be reused across multiple netdev_bind_rx calls. This commit fixes that by always passing in a newly created queue array to all netdev_bind_rx calls in ncdevmem. Fixes: 85585b4bc8d8 ("selftests: add ncdevmem, netcat for devmem TCP") Signed-off-by: Cosmin Ratiu Acked-by: Stanislav Fomichev Reviewed-by: Joe Damato Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250508084434.1933069-1-cratiu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38c937dbd4e4305974c135e9ae3716bbcd738fd9 Author: Stanislav Fomichev Date: Thu Nov 7 10:12:05 2024 -0800 selftests: ncdevmem: Switch to AF_INET6 [ Upstream commit 933056357a8cf0c9b3fb2ecc4d2d8d142614f0a3 ] Use dualstack socket to support both v4 and v6. v4-mapped-v6 address can be used to do v4. Reviewed-by: Mina Almasry Reviewed-by: Joe Damato Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20241107181211.3934153-7-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 97c4e094a4b2 ("tests/ncdevmem: Fix double-free of queue array") Signed-off-by: Sasha Levin commit 04db681f3c7576cf92572b34cfcb933a0c413d09 Author: Stanislav Fomichev Date: Thu Nov 7 10:12:03 2024 -0800 selftests: ncdevmem: Make client_ip optional [ Upstream commit 0ebd75f5f2392c2ada04c6e11447415911fe1506 ] Support 3-tuple filtering by making client_ip optional. When -c is not passed, don't specify src-ip/src-port in the filter. Reviewed-by: Mina Almasry Reviewed-by: Joe Damato Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20241107181211.3934153-5-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 97c4e094a4b2 ("tests/ncdevmem: Fix double-free of queue array") Signed-off-by: Sasha Levin commit 0738648a7d6108cde752c543d1552650f54026d4 Author: Stanislav Fomichev Date: Thu Nov 7 10:12:02 2024 -0800 selftests: ncdevmem: Unify error handling [ Upstream commit bfccbaac1b45f9af7d76589d7e31ad921b50c0d7 ] There is a bunch of places where error() calls look out of place. Use the same error(1, errno, ...) pattern everywhere. Reviewed-by: Mina Almasry Reviewed-by: Joe Damato Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20241107181211.3934153-4-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 97c4e094a4b2 ("tests/ncdevmem: Fix double-free of queue array") Signed-off-by: Sasha Levin commit eb15f4f3801367eb2ed67bc9c0b64285c7212cf0 Author: Stanislav Fomichev Date: Thu Nov 7 10:12:01 2024 -0800 selftests: ncdevmem: Separate out dmabuf provider [ Upstream commit 8b9049af8066b4705d83bb7847ee3c960fc58d09 ] So we can plug the other ones in the future if needed. Reviewed-by: Mina Almasry Reviewed-by: Joe Damato Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20241107181211.3934153-3-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 97c4e094a4b2 ("tests/ncdevmem: Fix double-free of queue array") Signed-off-by: Sasha Levin commit f3380d119f6120306fff1dad869c5a69c115cdf5 Author: Stanislav Fomichev Date: Thu Nov 7 10:12:00 2024 -0800 selftests: ncdevmem: Redirect all non-payload output to stderr [ Upstream commit 6891f0b523e1ef452523ba43d67ca2a654760e78 ] That should make it possible to do expected payload validation on the caller side. Reviewed-by: Mina Almasry Reviewed-by: Joe Damato Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20241107181211.3934153-2-sdf@fomichev.me Signed-off-by: Jakub Kicinski Stable-dep-of: 97c4e094a4b2 ("tests/ncdevmem: Fix double-free of queue array") Signed-off-by: Sasha Levin commit d4d1561d17eb72908e4489c0900d96e0484fac20 Author: Matt Johnston Date: Thu May 8 13:18:32 2025 +0800 net: mctp: Don't access ifa_index when missing [ Upstream commit f11cf946c0a92c560a890d68e4775723353599e1 ] In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox "ip addr show". The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index). BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309 Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Reported-by: syzbot+e76d52dadc089b9d197f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68135815.050a0220.3a872c.000e.GAE@google.com/ Reported-by: syzbot+1065a199625a388fce60@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/681357d6.050a0220.14dd7d.000d.GAE@google.com/ Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20250508-mctp-addr-dump-v2-1-c8a53fd2dd66@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e5efcff49b356d191c7d094c07e3fe520dbceab Author: Eric Dumazet Date: Fri Dec 6 22:38:11 2024 +0000 mctp: no longer rely on net->dev_index_head[] [ Upstream commit 2d20773aec14996b6cc4db92d885028319be683d ] mctp_dump_addrinfo() is one of the last users of net->dev_index_head[] in the control path. Switch to for_each_netdev_dump() for better scalability. Use C99 for mctp_device_rtnl_msg_handlers[] to prepare future RTNL removal from mctp_dump_addrinfo() (mdev->addrs is not yet RCU protected) Signed-off-by: Eric Dumazet Cc: Matt Johnston Reviewed-by: Kuniyuki Iwashima Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20241206223811.1343076-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: f11cf946c0a9 ("net: mctp: Don't access ifa_index when missing") Signed-off-by: Sasha Levin commit 37050be74e806f3ce00716f470e4e9dca3d0d0fb Author: Hangbin Liu Date: Thu May 8 03:54:14 2025 +0000 tools/net/ynl: ethtool: fix crash when Hardware Clock info is missing [ Upstream commit 45375814eb3f4245956c0c85092a4eee4441d167 ] Fix a crash in the ethtool YNL implementation when Hardware Clock information is not present in the response. This ensures graceful handling of devices or drivers that do not provide this optional field. e.g. Traceback (most recent call last): File "/net/tools/net/ynl/pyynl/./ethtool.py", line 438, in main() ~~~~^^ File "/net/tools/net/ynl/pyynl/./ethtool.py", line 341, in main print(f'PTP Hardware Clock: {tsinfo["phc-index"]}') ~~~~~~^^^^^^^^^^^^^ KeyError: 'phc-index' Fixes: f3d07b02b2b8 ("tools: ynl: ethtool testing tool") Signed-off-by: Hangbin Liu Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250508035414.82974-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d1365ca80b012d8a7863e45949e413fb61fa4861 Author: Cong Wang Date: Tue May 6 21:35:58 2025 -0700 net_sched: Flush gso_skb list too during ->change() [ Upstream commit 2d3cbfd6d54a2c39ce3244f33f85c595844bd7b8 ] Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler") Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Fixes: d4b36210c2e6 ("net: pkt_sched: PIE AQM scheme") Reported-by: Will Reported-by: Savy Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 28826a89fdfd49f3291980c2e68b8a7c5d55e199 Author: Luiz Augusto von Dentz Date: Tue Apr 29 15:05:59 2025 -0400 Bluetooth: MGMT: Fix MGMT_OP_ADD_DEVICE invalid device flags [ Upstream commit 1e2e3044c1bc64a64aa0eaf7c17f7832c26c9775 ] Device flags could be updated in the meantime while MGMT_OP_ADD_DEVICE is pending on hci_update_passive_scan_sync so instead of setting the current_flags as cmd->user_data just do a lookup using hci_conn_params_lookup and use the latest stored flags. Fixes: a182d9c84f9c ("Bluetooth: MGMT: Fix Add Device to responding before completing") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 10c7f1c647da3b77ef8827d974a97b6530b64df0 Author: Zhu Yanjun Date: Tue May 6 17:10:08 2025 +0200 RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem [ Upstream commit d0706bfd3ee40923c001c6827b786a309e2a8713 ] Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes. The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time. The solution is to add the lock protection when this name is accessed in the function kobject_uevent(). Fixes: 779e0bf47632 ("RDMA/core: Do not indicate device ready when device enablement fails") Link: https://patch.msgid.link/r/20250506151008.75701-1-yanjun.zhu@linux.dev Reported-by: syzbot+e2ce9e275ecc70a30b72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e2ce9e275ecc70a30b72 Signed-off-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit de7acdb462912f59fa28ea57b46830cfa87c6fba Author: Geert Uytterhoeven Date: Fri May 2 13:10:35 2025 +0200 spi: loopback-test: Do not split 1024-byte hexdumps [ Upstream commit a73fa3690a1f3014d6677e368dce4e70767a6ba2 ] spi_test_print_hex_dump() prints buffers holding less than 1024 bytes in full. Larger buffers are truncated: only the first 512 and the last 512 bytes are printed, separated by a truncation message. The latter is confusing in case the buffer holds exactly 1024 bytes, as all data is printed anyway. Fix this by printing buffers holding up to and including 1024 bytes in full. Fixes: 84e0c4e5e2c4ef42 ("spi: add loopback test driver to allow for spi_master regression tests") Signed-off-by: Geert Uytterhoeven Link: https://patch.msgid.link/37ee1bc90c6554c9347040adabf04188c8f704aa.1746184171.git.geert+renesas@glider.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit da824f1271633bcb515ca8084cda3eda4b3ace51 Author: Li Lingfeng Date: Thu Apr 17 15:25:08 2025 +0800 nfs: handle failure of nfs_get_lock_context in unlock path [ Upstream commit c457dc1ec770a22636b473ce5d35614adfe97636 ] When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example: BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]--- Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference. Fixes: f30cb757f680 ("NFS: Always wait for I/O completion before unlock") Signed-off-by: Li Lingfeng Reviewed-by: Jeff Layton Link: https://lore.kernel.org/r/20250417072508.3850532-1-lilingfeng3@huawei.com Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 94e7272b636a0677082e0604609e4c471e0a2caf Author: Henry Martin Date: Tue Apr 1 17:48:53 2025 +0800 HID: uclogic: Add NULL check in uclogic_input_configured() [ Upstream commit bd07f751208ba190f9b0db5e5b7f35d5bb4a8a1e ] devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: dd613a4e45f8 ("HID: uclogic: Correct devm device reference for hidinput input_dev name") Signed-off-by: Henry Martin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a6999953707a9c63cbddbef8eb74bf20cde18f67 Author: Qasim Ijaz Date: Thu Mar 27 23:11:46 2025 +0000 HID: thrustmaster: fix memory leak in thrustmaster_interrupts() [ Upstream commit 09d546303b370113323bfff456c4e8cff8756005 ] In thrustmaster_interrupts(), the allocated send_buf is not freed if the usb_check_int_endpoints() check fails, leading to a memory leak. Fix this by ensuring send_buf is freed before returning in the error path. Fixes: 50420d7c79c3 ("HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check") Signed-off-by: Qasim Ijaz Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 336edd6b0f5b7fbffc3e065285610624f59e88df Author: Zhu Yanjun Date: Sat Apr 12 09:57:14 2025 +0200 RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug [ Upstream commit f81b33582f9339d2dc17c69b92040d3650bb4bae ] Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur. The solution is to let rxe_cleanup do all the work. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://paste.ubuntu.com/p/tJgC42wDf6/ Tested-by: liuyi Signed-off-by: Zhu Yanjun Link: https://patch.msgid.link/20250412075714.3257358-1-yanjun.zhu@linux.dev Reviewed-by: Daisuke Matsuda Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c43b0a185fa6d5a0e868a48085c6fe89a757a4cc Author: Koichiro Den Date: Fri Dec 6 10:10:47 2024 +0900 virtio_net: ensure netdev_tx_reset_queue is called on bind xsk for tx [ Upstream commit 76a771ec4c9adfd75fe53c8505cf656a075d7101 ] virtnet_sq_bind_xsk_pool() flushes tx skbs and then resets tx queue, so DQL counters need to be reset when flushing has actually occurred, Add virtnet_sq_free_unused_buf_done() as a callback for virtqueue_resize() to handle this. Fixes: 21a4e3ce6dc7 ("virtio_net: xsk: bind/unbind xsk for tx") Signed-off-by: Koichiro Den Acked-by: Jason Wang Reviewed-by: Xuan Zhuo Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 343a77562c1f4b0ef500c5859a8e3e72989ca4c4 Author: Koichiro Den Date: Fri Dec 6 10:10:46 2024 +0900 virtio_ring: add a func argument 'recycle_done' to virtqueue_reset() [ Upstream commit 8d2da07c813ad333c20eb803e15f8c4541f25350 ] When virtqueue_reset() has actually recycled all unused buffers, additional work may be required in some cases. Relying solely on its return status is fragile, so introduce a new function argument 'recycle_done', which is invoked when it really occurs. Signed-off-by: Koichiro Den Acked-by: Jason Wang Reviewed-by: Xuan Zhuo Signed-off-by: Paolo Abeni Stable-dep-of: 76a771ec4c9a ("virtio_net: ensure netdev_tx_reset_queue is called on bind xsk for tx") Signed-off-by: Sasha Levin commit 1cf8bdd596a83594d3401d3c23b966f39b184c51 Author: David Lechner Date: Thu Apr 17 11:52:37 2025 -0500 iio: chemical: sps30: use aligned_s64 for timestamp [ Upstream commit bb49d940344bcb8e2b19e69d7ac86f567887ea9a ] Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure that the timestamp is correctly aligned on all architectures. Fixes: a5bf6fdd19c3 ("iio:chemical:sps30: Fix timestamp alignment") Signed-off-by: David Lechner Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-5-eafac1e22318@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7b16d3c36123f88125493886e1ac58bf2ba59234 Author: Jonathan Cameron Date: Sun Apr 13 11:34:25 2025 +0100 iio: adc: ad7768-1: Fix insufficient alignment of timestamp. [ Upstream commit ffbc26bc91c1f1eb3dcf5d8776e74cbae21ee13a ] On architectures where an s64 is not 64-bit aligned, this may result insufficient alignment of the timestamp and the structure being too small. Use aligned_s64 to force the alignment. Fixes: a1caeebab07e ("iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp()") # aligned_s64 newer Reported-by: David Lechner Reviewed-by: Nuno Sá Reviewed-by: David Lechner Link: https://patch.msgid.link/20250413103443.2420727-3-jic23@kernel.org Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b9e0997f2e8477ec7f3e9d9898fd16c56e0eb541 Author: Mathias Nyman Date: Mon May 5 15:56:30 2025 +0300 xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive. [ Upstream commit cab63934c33b12c0d1e9f4da7450928057f2c142 ] Event polling delay is set to 0 if there are any pending requests in either rx or tx requests lists. Checking for pending requests does not work well for "IN" transfers as the tty driver always queues requests to the list and TRBs to the ring, preparing to receive data from the host. This causes unnecessary busylooping and cpu hogging. Only set the event polling delay to 0 if there are pending tx "write" transfers, or if it was less than 10ms since last active data transfer in any direction. Cc: Łukasz Bartosik Fixes: fb18e5bb9660 ("xhci: dbc: poll at different rate depending on data transfer activity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250505125630.561699-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 651eaaae6baaa739ee234120ed2fc6fc720f81f5 Author: Mathias Nyman Date: Fri Dec 27 14:01:38 2024 +0200 xhci: dbc: Improve performance by removing delay in transfer event polling. [ Upstream commit 03e3d9c2bd85cda941b3cf78e895c1498ac05c5f ] Queue event polling work with 0 delay in case there are pending transfers queued up. This is part 2 of a 3 part series that roughly triples dbc performace when using adb push and pull over dbc. Max/min push rate after patches is 210/118 MB/s, pull rate 171/133 MB/s, tested with large files (300MB-9GB) by Łukasz Bartosik First performance improvement patch was commit 31128e7492dc ("xhci: dbc: add dbgtty request to end of list once it completes") Cc: Łukasz Bartosik Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241227120142.1035206-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: cab63934c33b ("xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive.") Signed-off-by: Sasha Levin commit 5d9d62323e1893e6f429fad7da19a652088cac21 Author: Alex Deucher Date: Thu May 1 13:00:16 2025 -0400 Revert "drm/amd: Stop evicting resources on APUs in suspend" [ Upstream commit d0ce1aaa8531a4a4707711cab5721374751c51b0 ] This reverts commit 3a9626c816db901def438dc2513622e281186d39. This breaks S4 because we end up setting the s3/s0ix flags even when we are entering s4 since prepare is used by both flows. The causes both the S3/s0ix and s4 flags to be set which breaks several checks in the driver which assume they are mutually exclusive. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3634 Cc: Mario Limonciello Reviewed-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit ce8f7d95899c2869b47ea6ce0b3e5bf304b2fff4) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4d45a5f1e2a04f5f84d5d5121dfbfff8d65c9c1c Author: Mario Limonciello Date: Wed Nov 27 21:26:56 2024 -0600 drm/amd: Add Suspend/Hibernate notification callback support [ Upstream commit 2965e6355dcdf157b5fafa25a2715f00064da8bf ] As part of the suspend sequence VRAM needs to be evicted on dGPUs. In order to make suspend/resume more reliable we moved this into the pmops prepare() callback so that the suspend sequence would fail but the system could remain operational under high memory usage suspend. Another class of issues exist though where due to memory fragementation there isn't a large enough contiguous space and swap isn't accessible. Add support for a suspend/hibernate notification callback that could evict VRAM before tasks are frozen. This should allow paging out to swap if necessary. Link: https://github.com/ROCm/ROCK-Kernel-Driver/issues/174 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3476 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2362 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3781 Reviewed-by: Lijo Lazar Link: https://lore.kernel.org/r/20241128032656.2090059-2-superm1@kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Stable-dep-of: d0ce1aaa8531 ("Revert "drm/amd: Stop evicting resources on APUs in suspend"") Signed-off-by: Sasha Levin commit ea0153e065f4a07407f085164dcd489b73ceded9 Author: David Lechner Date: Fri Apr 18 11:17:14 2025 -0500 iio: pressure: mprls0025pa: use aligned_s64 for timestamp [ Upstream commit ffcd19e9f4cca0c8f9e23e88f968711acefbb37b ] Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure the struct itself it also 8-byte aligned. While touching this, convert struct mpr_chan to an anonymous struct to consolidate the code a bit to make it easier for future readers. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: David Lechner Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-2-d6a5d2b1c9fe@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 039681d656a36621fbc575ea51ba2b8bf63919b3 Author: David Lechner Date: Thu Apr 17 11:52:36 2025 -0500 iio: chemical: pms7003: use aligned_s64 for timestamp [ Upstream commit 6ffa698674053e82e811520642db2650d00d2c01 ] Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure that the timestamp is correctly aligned on all architectures. Also move the unaligned.h header while touching this since it was the only one not in alphabetical order. Fixes: 13e945631c2f ("iio:chemical:pms7003: Fix timestamp alignment and prevent data leak.") Signed-off-by: David Lechner Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-4-eafac1e22318@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b37c112ef2655b38216969fa21fdaf288a69064c Author: Jonathan Cameron Date: Sun Apr 13 11:34:24 2025 +0100 iio: adc: ad7266: Fix potential timestamp alignment issue. [ Upstream commit 52d349884738c346961e153f195f4c7fe186fcf4 ] On architectures where an s64 is only 32-bit aligned insufficient padding would be left between the earlier elements and the timestamp. Use aligned_s64 to enforce the correct placement and ensure the storage is large enough. Fixes: 54e018da3141 ("iio:ad7266: Mark transfer buffer as __be16") # aligned_s64 is much newer. Reported-by: David Lechner Reviewed-by: Nuno Sá Reviewed-by: David Lechner Link: https://patch.msgid.link/20250413103443.2420727-2-jic23@kernel.org Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a065f78eba2aa50a8893d449eaf5f0859bd36550 Author: Sean Christopherson Date: Wed Apr 30 15:09:54 2025 -0700 KVM: x86/mmu: Prevent installing hugepages when mem attributes are changing [ Upstream commit 9129633d568edd36aa22bf703b12835153cec985 ] When changing memory attributes on a subset of a potential hugepage, add the hugepage to the invalidation range tracking to prevent installing a hugepage until the attributes are fully updated. Like the actual hugepage tracking updates in kvm_arch_post_set_memory_attributes(), process only the head and tail pages, as any potential hugepages that are entirely covered by the range will already be tracked. Note, only hugepage chunks whose current attributes are NOT mixed need to be added to the invalidation set, as mixed attributes already prevent installing a hugepage, and it's perfectly safe to install a smaller mapping for a gfn whose attributes aren't changing. Fixes: 8dd2eee9d526 ("KVM: x86/mmu: Handle page fault for private memory") Cc: stable@vger.kernel.org Reported-by: Michael Roth Tested-by: Michael Roth Link: https://lore.kernel.org/r/20250430220954.522672-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 3d962ec543e597b11df159283d31ab91d03ee488 Author: Isaku Yamahata Date: Thu Jul 18 14:12:14 2024 -0700 KVM: Add member to struct kvm_gfn_range to indicate private/shared [ Upstream commit dca6c88532322830d5d92486467fcc91b67a9ad8 ] Add new members to strut kvm_gfn_range to indicate which mapping (private-vs-shared) to operate on: enum kvm_gfn_range_filter attr_filter. Update the core zapping operations to set them appropriately. TDX utilizes two GPA aliases for the same memslots, one for memory that is for private memory and one that is for shared. For private memory, KVM cannot always perform the same operations it does on memory for default VMs, such as zapping pages and having them be faulted back in, as this requires guest coordination. However, some operations such as guest driven conversion of memory between private and shared should zap private memory. Internally to the MMU, private and shared mappings are tracked on separate roots. Mapping and zapping operations will operate on the respective GFN alias for each root (private or shared). So zapping operations will by default zap both aliases. Add fields in struct kvm_gfn_range to allow callers to specify which aliases so they can only target the aliases appropriate for their specific operation. There was feedback that target aliases should be specified such that the default value (0) is to operate on both aliases. Several options were considered. Several variations of having separate bools defined such that the default behavior was to process both aliases. They either allowed nonsensical configurations, or were confusing for the caller. A simple enum was also explored and was close, but was hard to process in the caller. Instead, use an enum with the default value (0) reserved as a disallowed value. Catch ranges that didn't have the target aliases specified by looking for that specific value. Set target alias with enum appropriately for these MMU operations: - For KVM's mmu notifier callbacks, zap shared pages only because private pages won't have a userspace mapping - For setting memory attributes, kvm_arch_pre_set_memory_attributes() chooses the aliases based on the attribute. - For guest_memfd invalidations, zap private only. Link: https://lore.kernel.org/kvm/ZivIF9vjKcuGie3s@google.com/ Signed-off-by: Isaku Yamahata Co-developed-by: Rick Edgecombe Signed-off-by: Rick Edgecombe Message-ID: <20240718211230.1492011-3-rick.p.edgecombe@intel.com> Signed-off-by: Paolo Bonzini Stable-dep-of: 9129633d568e ("KVM: x86/mmu: Prevent installing hugepages when mem attributes are changing") Signed-off-by: Sasha Levin commit 54401e29ab4fddb8ae54341f95d5e6923b7f392b Author: Naman Jain Date: Fri May 2 13:18:10 2025 +0530 uio_hv_generic: Fix sysfs creation path for ring buffer [ Upstream commit f31fe8165d365379d858c53bef43254c7d6d1cfd ] On regular bootup, devices get registered to VMBus first, so when uio_hv_generic driver for a particular device type is probed, the device is already initialized and added, so sysfs creation in hv_uio_probe() works fine. However, when the device is removed and brought back, the channel gets rescinded and the device again gets registered to VMBus. However this time, the uio_hv_generic driver is already registered to probe for that device and in this case sysfs creation is tried before the device's kobject gets initialized completely. Fix this by moving the core logic of sysfs creation of ring buffer, from uio_hv_generic to HyperV's VMBus driver, where the rest of the sysfs attributes for the channels are defined. While doing that, make use of attribute groups and macros, instead of creating sysfs directly, to ensure better error handling and code flow. Problematic path: vmbus_process_offer (A new offer comes for the VMBus device) vmbus_add_channel_work vmbus_device_register |-> device_register | |... | |-> hv_uio_probe | |... | |-> sysfs_create_bin_file (leads to a warning as | the primary channel's kobject, which is used to | create the sysfs file, is not yet initialized) |-> kset_create_and_add |-> vmbus_add_channel_kobj (initialization of the primary channel's kobject happens later) Above code flow is sequential and the warning is always reproducible in this path. Fixes: 9ab877a6ccf8 ("uio_hv_generic: make ring buffer attribute for primary channel") Cc: stable@kernel.org Suggested-by: Saurabh Sengar Suggested-by: Michael Kelley Reviewed-by: Michael Kelley Tested-by: Michael Kelley Reviewed-by: Dexuan Cui Signed-off-by: Naman Jain Link: https://lore.kernel.org/r/20250502074811.2022-2-namjain@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7bf64cd0ccb88ab0c6a69d23e6b0330e5751b4fc Author: Michal Suchanek Date: Fri Apr 4 10:23:14 2025 +0200 tpm: tis: Double the timeout B to 4s [ Upstream commit 2f661f71fda1fc0c42b7746ca5b7da529eb6b5be ] With some Infineon chips the timeouts in tpm_tis_send_data (both B and C) can reach up to about 2250 ms. Timeout C is retried since commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices") Timeout B still needs to be extended. The problem is most commonly encountered with context related operation such as load context/save context. These are issued directly by the kernel, and there is no retry logic for them. When a filesystem is set up to use the TPM for unlocking the boot fails, and restarting the userspace service is ineffective. This is likely because ignoring a load context/save context result puts the real TPM state and the TPM state expected by the kernel out of sync. Chips known to be affected: tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54) Description: SLB9672 Firmware Revision: 15.22 tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22) Firmware Revision: 7.83 tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16) Firmware Revision: 5.63 Link: https://lore.kernel.org/linux-integrity/Z5pI07m0Muapyu9w@kitsune.suse.cz/ Signed-off-by: Michal Suchanek Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 517c11fe4fcbfbafeffa48a4f9727859ffd85a6e Author: Masami Hiramatsu (Google) Date: Sat May 10 12:44:41 2025 +0900 tracing: probes: Fix a possible race in trace_probe_log APIs [ Upstream commit fd837de3c9cb1a162c69bc1fb1f438467fe7f2f5 ] Since the shared trace_probe_log variable can be accessed and modified via probe event create operation of kprobe_events, uprobe_events, and dynamic_events, it should be protected. In the dynamic_events, all operations are serialized by `dyn_event_ops_mutex`. But kprobe_events and uprobe_events interfaces are not serialized. To solve this issue, introduces dyn_event_create(), which runs create() operation under the mutex, for kprobe_events and uprobe_events. This also uses lockdep to check the mutex is held when using trace_probe_log* APIs. Link: https://lore.kernel.org/all/174684868120.551552.3068655787654268804.stgit@devnote2/ Reported-by: Paul Cacheux Closes: https://lore.kernel.org/all/20250510074456.805a16872b591e2971a4d221@kernel.org/ Fixes: ab105a4fb894 ("tracing: Use tracing error_log with probe events") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit f0d70d8dcae4de999183699d8cd41bca302e0d82 Author: Waiman Long Date: Thu May 8 15:24:13 2025 -0400 cgroup/cpuset: Extend kthread_is_per_cpu() check to all PF_NO_SETAFFINITY tasks [ Upstream commit 39b5ef791d109dd54c7c2e6e87933edfcc0ad1ac ] Commit ec5fbdfb99d1 ("cgroup/cpuset: Enable update_tasks_cpumask() on top_cpuset") enabled us to pull CPUs dedicated to child partitions from tasks in top_cpuset by ignoring per cpu kthreads. However, there can be other kthreads that are not per cpu but have PF_NO_SETAFFINITY flag set to indicate that we shouldn't mess with their CPU affinity. For other kthreads, their affinity will be changed to skip CPUs dedicated to child partitions whether it is an isolating or a scheduling one. As all the per cpu kthreads have PF_NO_SETAFFINITY set, the PF_NO_SETAFFINITY tasks are essentially a superset of per cpu kthreads. Fix this issue by dropping the kthread_is_per_cpu() check and checking the PF_NO_SETAFFINITY flag instead. Fixes: ec5fbdfb99d1 ("cgroup/cpuset: Enable update_tasks_cpumask() on top_cpuset") Signed-off-by: Waiman Long Acked-by: Frederic Weisbecker Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 220444d2095a0f455bf312839eb3df1fc784ad15 Author: Himanshu Bhavani Date: Mon May 5 11:28:27 2025 +0530 arm64: dts: imx8mp-var-som: Fix LDO5 shutdown causing SD card timeout [ Upstream commit c6888983134e2ccc2db8ffd2720b0d4826d952e4 ] Fix SD card timeout issue caused by LDO5 regulator getting disabled after boot. The kernel log shows LDO5 being disabled, which leads to a timeout on USDHC2: [ 33.760561] LDO5: disabling [ 81.119861] mmc1: Timeout waiting for hardware interrupt. To prevent this, set regulator-boot-on and regulator-always-on for LDO5. Also add the vqmmc regulator to properly support 1.8V/3.3V signaling for USDHC2 using a GPIO-controlled regulator. Fixes: 6c2a1f4f71258 ("arm64: dts: imx8mp-var-som-symphony: Add Variscite Symphony board and VAR-SOM-MX8MP SoM") Signed-off-by: Himanshu Bhavani Acked-by: Tarang Raval Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 48fff1267e8dc72e226d5451d543bcecce469c09 Author: Hans de Goede Date: Thu May 1 15:17:02 2025 +0200 platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection [ Upstream commit bfcfe6d335a967f8ea0c1980960e6f0205b5de6e ] The wlan_ctrl_by_user detection was introduced by commit a50bd128f28c ("asus-wmi: record wlan status while controlled by userapp"). Quoting from that commit's commit message: """ When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return (1) 0x00050001 (On) (2) 0x00050000 (Off) (3) 0x00030001 (On) (4) 0x00030000 (Off) (5) 0x00000002 (Unknown) (1), (2) means that the model has hardware GPIO for WLAN, you can call WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off. (3), (4) means that the model doesn’t have hardware GPIO, you need to use API or driver library to turn WLAN on/off, and call WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status. After you set WLAN LED status, you can see the WLAN status is changed with WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly (ex: Windows), you can use it for synchronization. (5) means that the model doesn’t have WLAN device. WLAN is the ONLY special case with upper rule. """ The wlan_ctrl_by_user flag should be set on 0x0003000? ((3), (4) above) return values, but the flag mistakenly also gets set on laptops with 0x0005000? ((1), (2)) return values. This is causing rfkill problems on laptops where 0x0005000? is returned. Fix the check to only set the wlan_ctrl_by_user flag for 0x0003000? return values. Fixes: a50bd128f28c ("asus-wmi: record wlan status while controlled by userapp") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219786 Signed-off-by: Hans de Goede Reviewed-by: Armin Wolf Link: https://lore.kernel.org/r/20250501131702.103360-2-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 03e4ee3a9a2650776fa3935bdbcf71f27c8ebf67 Author: Runhua He Date: Wed May 7 18:01:03 2025 +0800 platform/x86/amd/pmc: Declare quirk_spurious_8042 for MECHREVO Wujie 14XA (GX4HRXL) [ Upstream commit 0887817e4953885fbd6a5c1bec2fdd339261eb19 ] MECHREVO Wujie 14XA (GX4HRXL) wakes up immediately after s2idle entry. This happens regardless of whether the laptop is plugged into AC power, or whether any peripheral is plugged into the laptop. Similar to commit a55bdad5dfd1 ("platform/x86/amd/pmc: Disable keyboard wakeup on AMD Framework 13"), the MECHREVO Wujie 14XA wakes up almost instantly after s2idle suspend entry (IRQ1 is the keyboard): 2025-04-18 17:23:57,588 DEBUG: PM: Triggering wakeup from IRQ 9 2025-04-18 17:23:57,588 DEBUG: PM: Triggering wakeup from IRQ 1 Add this model to the spurious_8042 quirk to workaround this. This patch does not affect the wake-up function of the built-in keyboard. Because the firmware of this machine adds an insurance for keyboard wake-up events, as it always triggers an additional IRQ 9 to wake up the system. Suggested-by: Mingcong Bai Suggested-by: Xinhui Yang Suggested-by: Rong Zhang Fixes: a55bdad5dfd1 ("platform/x86/amd/pmc: Disable keyboard wakeup on AMD Framework 13") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4166 Cc: Mario Limonciello Link: https://zhuanldan.zhihu.com/p/730538041 Tested-by: Yemu Lu Signed-off-by: Runhua He Link: https://lore.kernel.org/r/20250507100103.995395-1-hua@aosc.io Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit bc4c54cbb430e6e953054a242c8307b352fd34fe Author: Kees Cook Date: Fri Apr 25 15:45:06 2025 -0700 binfmt_elf: Move brk for static PIE even if ASLR disabled [ Upstream commit 11854fe263eb1b9a8efa33b0c087add7719ea9b4 ] In commit bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec"), the brk was moved out of the mmap region when loading static PIE binaries (ET_DYN without INTERP). The common case for these binaries was testing new ELF loaders, so the brk needed to be away from mmap to avoid colliding with stack, future mmaps (of the loader-loaded binary), etc. But this was only done when ASLR was enabled, in an attempt to minimize changes to memory layouts. After adding support to respect alignment requirements for static PIE binaries in commit 3545deff0ec7 ("binfmt_elf: Honor PT_LOAD alignment for static PIE"), it became possible to have a large gap after the final PT_LOAD segment and the top of the mmap region. This means that future mmap allocations might go after the last PT_LOAD segment (where brk might be if ASLR was disabled) instead of before them (where they traditionally ended up). On arm64, running with ASLR disabled, Ubuntu 22.04's "ldconfig" binary, a static PIE, has alignment requirements that leaves a gap large enough after the last PT_LOAD segment to fit the vdso and vvar, but still leave enough space for the brk (which immediately follows the last PT_LOAD segment) to be allocated by the binary. fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /sbin/ldconfig.real fffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /sbin/ldconfig.real fffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0 ***[brk will go here at fffff7ffa000]*** fffff7ffc000-fffff7ffe000 r--p 00000000 00:00 0 [vvar] fffff7ffe000-fffff8000000 r-xp 00000000 00:00 0 [vdso] fffffffdf000-1000000000000 rw-p 00000000 00:00 0 [stack] After commit 0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation"), the arm64 vvar grew slightly, and suddenly the brk collided with the allocation. fffff7f20000-fffff7fde000 r-xp 00000000 fe:02 8110426 /sbin/ldconfig.real fffff7fee000-fffff7ff5000 rw-p 000be000 fe:02 8110426 /sbin/ldconfig.real fffff7ff5000-fffff7ffa000 rw-p 00000000 00:00 0 ***[oops, no room any more, vvar is at fffff7ffa000!]*** fffff7ffa000-fffff7ffe000 r--p 00000000 00:00 0 [vvar] fffff7ffe000-fffff8000000 r-xp 00000000 00:00 0 [vdso] fffffffdf000-1000000000000 rw-p 00000000 00:00 0 [stack] The solution is to unconditionally move the brk out of the mmap region for static PIE binaries. Whether ASLR is enabled or not does not change if there may be future mmap allocation collisions with a growing brk region. Update memory layout comments (with kernel-doc headings), consolidate the setting of mm->brk to later (it isn't needed early), move static PIE brk out of mmap unconditionally, and make sure brk(2) knows to base brk position off of mm->start_brk not mm->end_data no matter what the cause of moving it is (via current->brk_randomized). For the CONFIG_COMPAT_BRK case, though, leave the logic unchanged, as we can never safely move the brk. These systems, however, are not using specially aligned static PIE binaries. Reported-by: Ryan Roberts Closes: https://lore.kernel.org/lkml/f93db308-4a0e-4806-9faf-98f890f5a5e6@arm.com/ Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec") Link: https://lore.kernel.org/r/20250425224502.work.520-kees@kernel.org Reviewed-by: Ryan Roberts Tested-by: Ryan Roberts Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 97dd8c19f2a3826014b940e191d1e19da867bc3a Author: Ze Huang Date: Mon Apr 28 17:24:36 2025 +0800 riscv: dts: sophgo: fix DMA data-width configuration for CV18xx [ Upstream commit 3e6244429ba38f8dee3336b8b805948276b281ab ] The "snps,data-width" property[1] defines the AXI data width of the DMA controller as: width = 8 × (2^n) bits (0 = 8 bits, 1 = 16 bits, 2 = 32 bits, ..., 6 = 512 bits) where "n" is the value of "snps,data-width". For the CV18xx DMA controller, the correct AXI data width is 32 bits, corresponding to "snps,data-width = 2". Test results on Milkv Duo S can be found here [2]. Link: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/dma/snps%2Cdw-axi-dmac.yaml#L74 [1] Link: https://gist.github.com/Sutter099/4fa99bb2d89e5af975983124704b3861 [2] Fixes: 514951a81a5e ("riscv: dts: sophgo: cv18xx: add DMA controller") Co-developed-by: Yu Yuan Signed-off-by: Yu Yuan Signed-off-by: Ze Huang Link: https://lore.kernel.org/r/20250428-duo-dma-config-v1-1-eb6ad836ca42@whut.edu.cn Signed-off-by: Inochi Amaoto Signed-off-by: Chen Wang Signed-off-by: Chen Wang Signed-off-by: Sasha Levin commit a0bde67526c04c44cfdb45f5c0ea667eb3592b70 Author: Mario Limonciello Date: Wed Apr 23 08:18:45 2025 -0500 drivers/platform/x86/amd: pmf: Check for invalid Smart PC Policies [ Upstream commit 8e81b9cd6e95188d12c9cc25d40b61dd5ea05ace ] commit 376a8c2a14439 ("platform/x86/amd/pmf: Update PMF Driver for Compatibility with new PMF-TA") added support for platforms that support an updated TA, however it also exposed a number of platforms that although they have support for the updated TA don't actually populate a policy binary. Add an explicit check that the policy binary isn't empty before initializing the TA. Reported-by: Christian Heusel Closes: https://lore.kernel.org/platform-driver-x86/ae644428-5bf2-4b30-81ba-0b259ed3449b@heusel.eu/ Fixes: 376a8c2a14439 ("platform/x86/amd/pmf: Update PMF Driver for Compatibility with new PMF-TA") Signed-off-by: Mario Limonciello Tested-by: Christian Heusel Link: https://lore.kernel.org/r/20250423132002.3984997-3-superm1@kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5022d7a3925560fd1b6c4d7de494348420f4ed63 Author: Mario Limonciello Date: Wed Apr 23 08:18:44 2025 -0500 drivers/platform/x86/amd: pmf: Check for invalid sideloaded Smart PC Policies [ Upstream commit 690d722e02819ef978f90cd7553973eba1007e6c ] If a policy is passed into amd_pmf_get_pb_data() that causes the engine to fail to start there is a memory leak. Free the memory in this failure path. Fixes: 10817f28e5337 ("platform/x86/amd/pmf: Add capability to sideload of policy binary") Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20250423132002.3984997-2-superm1@kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 10d1496f85d722e86d3b0a33cf68c8a342cddc90 Author: Stephen Smalley Date: Thu Apr 24 11:28:20 2025 -0400 fs/xattr.c: fix simple_xattr_list to always include security.* xattrs [ Upstream commit 8b0ba61df5a1c44e2b3cf683831a4fc5e24ea99d ] The vfs has long had a fallback to obtain the security.* xattrs from the LSM when the filesystem does not implement its own listxattr, but shmem/tmpfs and kernfs later gained their own xattr handlers to support other xattrs. Unfortunately, as a side effect, tmpfs and kernfs-based filesystems like sysfs no longer return the synthetic security.* xattr names via listxattr unless they are explicitly set by userspace or initially set upon inode creation after policy load. coreutils has recently switched from unconditionally invoking getxattr for security.* for ls -Z via libselinux to only doing so if listxattr returns the xattr name, breaking ls -Z of such inodes. Before: $ getfattr -m.* /run/initramfs $ getfattr -m.* /sys/kernel/fscaps $ setfattr -n user.foo /run/initramfs $ getfattr -m.* /run/initramfs user.foo After: $ getfattr -m.* /run/initramfs security.selinux $ getfattr -m.* /sys/kernel/fscaps security.selinux $ setfattr -n user.foo /run/initramfs $ getfattr -m.* /run/initramfs security.selinux user.foo Link: https://lore.kernel.org/selinux/CAFqZXNtF8wDyQajPCdGn=iOawX4y77ph0EcfcqcUUj+T87FKyA@mail.gmail.com/ Link: https://lore.kernel.org/selinux/20250423175728.3185-2-stephen.smalley.work@gmail.com/ Signed-off-by: Stephen Smalley Link: https://lore.kernel.org/20250424152822.2719-1-stephen.smalley.work@gmail.com Fixes: b09e0fa4b4ea66266058ee ("tmpfs: implement generic xattr support") Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 61f489ca99407399deaab815b7f8efa7d0889246 Author: Tom Vincent Date: Thu Apr 17 09:17:53 2025 +0100 arm64: dts: rockchip: Assign RT5616 MCLK rate on rk3588-friendlyelec-cm3588 [ Upstream commit 5e6a4ee9799b202fefa8c6264647971f892f0264 ] The Realtek RT5616 audio codec on the FriendlyElec CM3588 module fails to probe correctly due to the missing clock properties. This results in distorted analogue audio output. Assign MCLK to 12.288 MHz, which allows the codec to advertise most of the standard sample rates per other RK3588 devices. Fixes: e23819cf273c ("arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board") Signed-off-by: Tom Vincent Link: https://lore.kernel.org/r/20250417081753.644950-1-linux@tlvince.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 6be381b1d3590ece5aa8b821ec467f2ad1be3b9a Author: Alexandre Frade Date: Sun May 18 16:02:37 2025 +0000 Linux 6.12.29-xanmod1 Signed-off-by: Alexandre Frade commit 863737b78ba9c3b94de3b7816533c512b54e0758 Merge: a0f5cbcaa5d0 5be5dbf91ef3 Author: Alexandre Frade Date: Sun May 18 15:59:13 2025 +0000 Merge tag 'v6.12.29' into 6.12 This is the 6.12.29 stable release commit 5be5dbf91ef3c8643d2a3698d557a52059702487 Author: Greg Kroah-Hartman Date: Sun May 18 08:25:00 2025 +0200 Linux 6.12.29 Link: https://lore.kernel.org/r/20250512172041.624042835@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Mark Brown Tested-by: Ron Economos Tested-by: Florian Fainelli Tested-by: Brett Mastbergen Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Hardik Garg Link: https://lore.kernel.org/r/20250514125624.330060065@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Harshit Mogalapalli Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Brett Mastbergen Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman commit 7e78061be78b8593df9b0cd0f21b1fee425035de Author: Peter Zijlstra Date: Wed Apr 23 09:57:31 2025 +0200 x86/its: FineIBT-paranoid vs ITS commit e52c1dc7455d32c8a55f9949d300e5e87d011fa6 upstream. FineIBT-paranoid was using the retpoline bytes for the paranoid check, disabling retpolines, because all parts that have IBT also have eIBRS and thus don't need no stinking retpolines. Except... ITS needs the retpolines for indirect calls must not be in the first half of a cacheline :-/ So what was the paranoid call sequence: : 0: 41 ba 78 56 34 12 mov $0x12345678, %r10d 6: 45 3b 53 f7 cmp -0x9(%r11), %r10d a: 4d 8d 5b lea -0x10(%r11), %r11 e: 75 fd jne d 10: 41 ff d3 call *%r11 13: 90 nop Now becomes: : 0: 41 ba 78 56 34 12 mov $0x12345678, %r10d 6: 45 3b 53 f7 cmp -0x9(%r11), %r10d a: 4d 8d 5b f0 lea -0x10(%r11), %r11 e: 2e e8 XX XX XX XX cs call __x86_indirect_paranoid_thunk_r11 Where the paranoid_thunk looks like: 1d: (bad) __x86_indirect_paranoid_thunk_r11: 1e: 75 fd jne 1d __x86_indirect_its_thunk_r11: 20: 41 ff eb jmp *%r11 23: cc int3 [ dhansen: remove initialization to false ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Alexandre Chartre [ Just a portion of the original commit, in order to fix a build issue in stable kernels due to backports ] Tested-by: Holger Hoffstätte Link: https://lore.kernel.org/r/20250514113952.GB16434@noisy.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit bb85c3abbfd89198324752a4c2c67d2b7db6ab79 Author: Eric Biggers Date: Mon May 12 19:58:39 2025 -0700 x86/its: Fix build errors when CONFIG_MODULES=n commit 9f35e33144ae5377d6a8de86dd3bd4d995c6ac65 upstream. Fix several build errors when CONFIG_MODULES=n, including the following: ../arch/x86/kernel/alternative.c:195:25: error: incomplete definition of type 'struct module' 195 | for (int i = 0; i < mod->its_num_pages; i++) { Fixes: 872df34d7c51 ("x86/its: Use dynamic thunks for indirect branches") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Acked-by: Dave Hansen Tested-by: Steven Rostedt (Google) Reviewed-by: Alexandre Chartre Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2a6194e124273d5f6dbdbb16d92466f418ebf0e9 Author: Pawan Gupta Date: Tue Dec 24 16:09:28 2024 -0800 selftest/x86/bugs: Add selftests for ITS commit 7a9b709e7cc5ce1ffb84ce07bf6d157e1de758df upstream. Below are the tests added for Indirect Target Selection (ITS): - its_sysfs.py - Check if sysfs reflects the correct mitigation status for the mitigation selected via the kernel cmdline. - its_permutations.py - tests mitigation selection with cmdline permutations with other bugs like spectre_v2 and retbleed. - its_indirect_alignment.py - verifies that for addresses in .retpoline_sites section that belong to lower half of cacheline are patched to ITS-safe thunk. Typical output looks like below: Site 49: function symbol: __x64_sys_restart_syscall+0x1f <0xffffffffbb1509af> # vmlinux: 0xffffffff813509af: jmp 0xffffffff81f5a8e0 # kcore: 0xffffffffbb1509af: jmpq *%rax # ITS thunk NOT expected for site 49 # PASSED: Found *%rax # Site 50: function symbol: __resched_curr+0xb0 <0xffffffffbb181910> # vmlinux: 0xffffffff81381910: jmp 0xffffffff81f5a8e0 # kcore: 0xffffffffbb181910: jmp 0xffffffffc02000fc # ITS thunk expected for site 50 # PASSED: Found 0xffffffffc02000fc -> jmpq *%rax - its_ret_alignment.py - verifies that for addresses in .return_sites section that belong to lower half of cacheline are patched to its_return_thunk. Typical output looks like below: Site 97: function symbol: collect_event+0x48 <0xffffffffbb007f18> # vmlinux: 0xffffffff81207f18: jmp 0xffffffff81f5b500 # kcore: 0xffffffffbb007f18: jmp 0xffffffffbbd5b560 # PASSED: Found jmp 0xffffffffbbd5b560 # Site 98: function symbol: collect_event+0xa4 <0xffffffffbb007f74> # vmlinux: 0xffffffff81207f74: jmp 0xffffffff81f5b500 # kcore: 0xffffffffbb007f74: retq # PASSED: Found retq Some of these tests have dependency on tools like virtme-ng[1] and drgn[2]. When the dependencies are not met, the test will be skipped. [1] https://github.com/arighi/virtme-ng [2] https://github.com/osandov/drgn Co-developed-by: Tao Zhang Signed-off-by: Tao Zhang Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Signed-off-by: Greg Kroah-Hartman commit 88a817e60dbbda17135800adf9704d0bdcbcf98f Author: Peter Zijlstra Date: Mon Oct 14 10:05:48 2024 -0700 x86/its: Use dynamic thunks for indirect branches commit 872df34d7c51a79523820ea6a14860398c639b87 upstream. ITS mitigation moves the unsafe indirect branches to a safe thunk. This could degrade the prediction accuracy as the source address of indirect branches becomes same for different execution paths. To improve the predictions, and hence the performance, assign a separate thunk for each indirect callsite. This is also a defense-in-depth measure to avoid indirect branches aliasing with each other. As an example, 5000 dynamic thunks would utilize around 16 bits of the address space, thereby gaining entropy. For a BTB that uses 32 bits for indexing, dynamic thunks could provide better prediction accuracy over fixed thunks. Have ITS thunks be variable sized and use EXECMEM_MODULE_TEXT such that they are both more flexible (got to extend them later) and live in 2M TLBs, just like kernel code, avoiding undue TLB pressure. [ pawan: CONFIG_EXECMEM_ROX is not supported on backport kernel, made adjustments to set memory to RW and ROX ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 15335117c5d73a0cc0404056c94cc8b6a371e25a Author: Pawan Gupta Date: Sat May 3 09:46:31 2025 -0700 x86/ibt: Keep IBT disabled during alternative patching commit ebebe30794d38c51f71fe4951ba6af4159d9837d upstream. cfi_rewrite_callers() updates the fineIBT hash matching at the caller side, but except for paranoid-mode it relies on apply_retpoline() and friends for any ENDBR relocation. This could temporarily cause an indirect branch to land on a poisoned ENDBR. For instance, with para-virtualization enabled, a simple wrmsrl() could have an indirect branch pointing to native_write_msr() who's ENDBR has been relocated due to fineIBT: : push %rbp mov %rsp,%rbp mov %esi,%eax mov %rsi,%rdx shr $0x20,%rdx mov %edi,%edi mov %rax,%rsi call *0x21e65d0(%rip) # ^^^^^^^^^^^^^^^^^^^^^^^ Such an indirect call during the alternative patching could #CP if the caller is not *yet* adjusted for the new target ENDBR. To prevent a false #CP, keep CET-IBT disabled until all callers are patched. Patching during the module load does not need to be guarded by IBT-disable because the module code is not executed until the patching is complete. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit bd57853b863ea427c8fa25f7eb61f03cb6baf5ad Author: Pawan Gupta Date: Fri May 2 06:25:19 2025 -0700 x86/its: Align RETs in BHB clear sequence to avoid thunking commit f0cd7091cc5a032c8870b4285305d9172569d126 upstream. The software mitigation for BHI is to execute BHB clear sequence at syscall entry, and possibly after a cBPF program. ITS mitigation thunks RETs in the lower half of the cacheline. This causes the RETs in the BHB clear sequence to be thunked as well, adding unnecessary branches to the BHB clear sequence. Since the sequence is in hot path, align the RET instructions in the sequence to avoid thunking. This is how disassembly clear_bhb_loop() looks like after this change: 0x44 <+4>: mov $0x5,%ecx 0x49 <+9>: call 0xffffffff81001d9b 0x4e <+14>: jmp 0xffffffff81001de5 0x53 <+19>: int3 ... 0x9b <+91>: call 0xffffffff81001dce 0xa0 <+96>: ret 0xa1 <+97>: int3 ... 0xce <+142>: mov $0x5,%eax 0xd3 <+147>: jmp 0xffffffff81001dd6 0xd5 <+149>: nop 0xd6 <+150>: sub $0x1,%eax 0xd9 <+153>: jne 0xffffffff81001dd3 0xdb <+155>: sub $0x1,%ecx 0xde <+158>: jne 0xffffffff81001d9b 0xe0 <+160>: ret 0xe1 <+161>: int3 0xe2 <+162>: int3 0xe3 <+163>: int3 0xe4 <+164>: int3 0xe5 <+165>: lfence 0xe8 <+168>: pop %rbp 0xe9 <+169>: ret Suggested-by: Andrew Cooper Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 9f132c0397df9cc073172560b6e4c975a4746c0e Author: Pawan Gupta Date: Mon Dec 2 12:07:08 2024 -0800 x86/its: Add support for RSB stuffing mitigation commit facd226f7e0c8ca936ac114aba43cb3e8b94e41e upstream. When retpoline mitigation is enabled for spectre-v2, enabling call-depth-tracking and RSB stuffing also mitigates ITS. Add cmdline option indirect_target_selection=stuff to allow enabling RSB stuffing mitigation. When retpoline mitigation is not enabled, =stuff option is ignored, and default mitigation for ITS is deployed. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 4dc1902fdee72dd9474c9878c7153cf3769f8294 Author: Pawan Gupta Date: Mon Nov 18 09:53:12 2024 -0800 x86/its: Add "vmexit" option to skip mitigation on some CPUs commit 2665281a07e19550944e8354a2024635a7b2714a upstream. Ice Lake generation CPUs are not affected by guest/host isolation part of ITS. If a user is only concerned about KVM guests, they can now choose a new cmdline option "vmexit" that will not deploy the ITS mitigation when CPU is not affected by guest/host isolation. This saves the performance overhead of ITS mitigation on Ice Lake gen CPUs. When "vmexit" option selected, if the CPU is affected by ITS guest/host isolation, the default ITS mitigation is deployed. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 68d59e9ba38424389168eddf8791265818f67292 Author: Pawan Gupta Date: Fri Jun 21 20:23:23 2024 -0700 x86/its: Enable Indirect Target Selection mitigation commit f4818881c47fd91fcb6d62373c57c7844e3de1c0 upstream. Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with eIBRS. It affects prediction of indirect branch and RETs in the lower half of cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the upper half of the cacheline. Scope of impact =============== Guest/host isolation -------------------- When eIBRS is used for guest/host isolation, the indirect branches in the VMM may still be predicted with targets corresponding to branches in the guest. Intra-mode ---------- cBPF or other native gadgets can be used for intra-mode training and disclosure using ITS. User/kernel isolation --------------------- When eIBRS is enabled user/kernel isolation is not impacted. Indirect Branch Prediction Barrier (IBPB) ----------------------------------------- After an IBPB, indirect branches may be predicted with targets corresponding to direct branches which were executed prior to IBPB. This is mitigated by a microcode update. Add cmdline parameter indirect_target_selection=off|on|force to control the mitigation to relocate the affected branches to an ITS-safe thunk i.e. located in the upper half of cacheline. Also add the sysfs reporting. When retpoline mitigation is deployed, ITS safe-thunks are not needed, because retpoline sequence is already ITS-safe. Similarly, when call depth tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return thunk is not used, as CDT prevents RSB-underflow. To not overcomplicate things, ITS mitigation is not supported with spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy lfence;jmp mitigation on ITS affected parts anyways. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 51000047235f8d14ead34749f59e3eee80fa1403 Author: Pawan Gupta Date: Fri Jun 21 21:17:21 2024 -0700 x86/its: Add support for ITS-safe return thunk commit a75bf27fe41abe658c53276a0c486c4bf9adecfc upstream. RETs in the lower half of cacheline may be affected by ITS bug, specifically when the RSB-underflows. Use ITS-safe return thunk for such RETs. RETs that are not patched: - RET in retpoline sequence does not need to be patched, because the sequence itself fills an RSB before RET. - RET in Call Depth Tracking (CDT) thunks __x86_indirect_{call|jump}_thunk and call_depth_return_thunk are not patched because CDT by design prevents RSB-underflow. - RETs in .init section are not reachable after init. - RETs that are explicitly marked safe with ANNOTATE_UNRET_SAFE. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 16a7d5b7a46ec0db7d30bb52d096a222fa0e22ed Author: Pawan Gupta Date: Fri Jun 21 21:17:21 2024 -0700 x86/its: Add support for ITS-safe indirect thunk commit 8754e67ad4ac692c67ff1f99c0d07156f04ae40c upstream. Due to ITS, indirect branches in the lower half of a cacheline may be vulnerable to branch target injection attack. Introduce ITS-safe thunks to patch indirect branches in the lower half of cacheline with the thunk. Also thunk any eBPF generated indirect branches in emit_indirect_jump(). Below category of indirect branches are not mitigated: - Indirect branches in the .init section are not mitigated because they are discarded after boot. - Indirect branches that are explicitly marked retpoline-safe. Note that retpoline also mitigates the indirect branches against ITS. This is because the retpoline sequence fills an RSB entry before RET, and it does not suffer from RSB-underflow part of the ITS. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit a6f2a436e9d6aa96013814cface08d8602638123 Author: Pawan Gupta Date: Fri Jun 21 17:40:41 2024 -0700 x86/its: Enumerate Indirect Target Selection (ITS) bug commit 159013a7ca18c271ff64192deb62a689b622d860 upstream. ITS bug in some pre-Alderlake Intel CPUs may allow indirect branches in the first half of a cache line get predicted to a target of a branch located in the second half of the cache line. Set X86_BUG_ITS on affected CPUs. Mitigation to follow in later commits. Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 76f847655bcbbeca672a4d5413a087fcf1d73e4e Author: Pawan Gupta Date: Fri Apr 11 15:36:38 2025 -0700 Documentation: x86/bugs/its: Add ITS documentation commit 1ac116ce6468670eeda39345a5585df308243dca upstream. Add the admin-guide for Indirect Target Selection (ITS). Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit f23d4f4aebf0f5c6e54f8bd2bf2498efeb2cd195 Author: Pawan Gupta Date: Thu Mar 20 11:13:15 2025 -0700 x86/speculation: Remove the extra #ifdef around CALL_NOSPEC commit c8c81458863ab686cda4fe1e603fccaae0f12460 upstream. Commit: 010c4a461c1d ("x86/speculation: Simplify and make CALL_NOSPEC consistent") added an #ifdef CONFIG_MITIGATION_RETPOLINE around the CALL_NOSPEC definition. This is not required as this code is already under a larger #ifdef. Remove the extra #ifdef, no functional change. vmlinux size remains same before and after this change: CONFIG_MITIGATION_RETPOLINE=y: text data bss dec hex filename 25434752 7342290 2301212 35078254 217406e vmlinux.before 25434752 7342290 2301212 35078254 217406e vmlinux.after # CONFIG_MITIGATION_RETPOLINE is not set: text data bss dec hex filename 22943094 6214994 1550152 30708240 1d49210 vmlinux.before 22943094 6214994 1550152 30708240 1d49210 vmlinux.after Signed-off-by: Pawan Gupta Signed-off-by: Ingo Molnar Reviewed-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20250320-call-nospec-extra-ifdef-v1-1-d9b084d24820@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9ebe6f1bd213bcce8f16c595bb3d47af262367f7 Author: Pawan Gupta Date: Fri Feb 28 18:35:58 2025 -0800 x86/speculation: Add a conditional CS prefix to CALL_NOSPEC commit 052040e34c08428a5a388b85787e8531970c0c67 upstream. Retpoline mitigation for spectre-v2 uses thunks for indirect branches. To support this mitigation compilers add a CS prefix with -mindirect-branch-cs-prefix. For an indirect branch in asm, this needs to be added manually. CS prefix is already being added to indirect branches in asm files, but not in inline asm. Add CS prefix to CALL_NOSPEC for inline asm as well. There is no JMP_NOSPEC for inline asm. Reported-by: Josh Poimboeuf Signed-off-by: Pawan Gupta Signed-off-by: Ingo Molnar Cc: Andrew Cooper Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250228-call-nospec-v3-2-96599fed0f33@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d2498bbb54f6962e6ea409c61241bb147fd48f49 Author: Pawan Gupta Date: Fri Feb 28 18:35:43 2025 -0800 x86/speculation: Simplify and make CALL_NOSPEC consistent commit cfceff8526a426948b53445c02bcb98453c7330d upstream. CALL_NOSPEC macro is used to generate Spectre-v2 mitigation friendly indirect branches. At compile time the macro defaults to indirect branch, and at runtime those can be patched to thunk based mitigations. This approach is opposite of what is done for the rest of the kernel, where the compile time default is to replace indirect calls with retpoline thunk calls. Make CALL_NOSPEC consistent with the rest of the kernel, default to retpoline thunk at compile time when CONFIG_MITIGATION_RETPOLINE is enabled. Signed-off-by: Pawan Gupta Signed-off-by: Ingo Molnar Cc: Andrew Cooper Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250228-call-nospec-v3-1-96599fed0f33@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9d8295dcf2434bc8f5e5efad775b83d8f51a5dfa Author: Pawan Gupta Date: Mon May 5 14:35:12 2025 -0700 x86/bhi: Do not set BHI_DIS_S in 32-bit mode commit 073fdbe02c69c43fb7c0d547ec265c7747d4a646 upstream. With the possibility of intra-mode BHI via cBPF, complete mitigation for BHI is to use IBHF (history fence) instruction with BHI_DIS_S set. Since this new instruction is only available in 64-bit mode, setting BHI_DIS_S in 32-bit mode is only a partial mitigation. Do not set BHI_DIS_S in 32-bit mode so as to avoid reporting misleading mitigated status. With this change IBHF won't be used in 32-bit mode, also remove the CONFIG_X86_64 check from emit_spectre_bhb_barrier(). Suggested-by: Josh Poimboeuf Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Reviewed-by: Josh Poimboeuf Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit b86349f326259d1c4afab58a5e84bdd04b28e4fd Author: Daniel Sneddon Date: Mon May 5 14:35:12 2025 -0700 x86/bpf: Add IBHF call at end of classic BPF commit 9f725eec8fc0b39bdc07dcc8897283c367c1a163 upstream. Classic BPF programs can be run by unprivileged users, allowing unprivileged code to execute inside the kernel. Attackers can use this to craft branch history in kernel mode that can influence the target of indirect branches. BHI_DIS_S provides user-kernel isolation of branch history, but cBPF can be used to bypass this protection by crafting branch history in kernel mode. To stop intra-mode attacks via cBPF programs, Intel created a new instruction Indirect Branch History Fence (IBHF). IBHF prevents the predicted targets of subsequent indirect branches from being influenced by branch history prior to the IBHF. IBHF is only effective while BHI_DIS_S is enabled. Add the IBHF instruction to cBPF jitted code's exit path. Add the new fence when the hardware mitigation is enabled (i.e., X86_FEATURE_CLEAR_BHB_HW is set) or after the software sequence (X86_FEATURE_CLEAR_BHB_LOOP) is being used in a virtual machine. Note that X86_FEATURE_CLEAR_BHB_HW and X86_FEATURE_CLEAR_BHB_LOOP are mutually exclusive, so the JIT compiler will only emit the new fence, not the SW sequence, when X86_FEATURE_CLEAR_BHB_HW is set. Hardware that enumerates BHI_NO basically has BHI_DIS_S protections always enabled, regardless of the value of BHI_DIS_S. Since BHI_DIS_S doesn't protect against intra-mode attacks, enumerate BHI bug on BHI_NO hardware as well. Signed-off-by: Daniel Sneddon Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Acked-by: Daniel Borkmann Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 87a12b9b3810265593996940fc100f686b171d98 Author: Daniel Sneddon Date: Mon May 5 14:35:12 2025 -0700 x86/bpf: Call branch history clearing sequence on exit commit d4e89d212d401672e9cdfe825d947ee3a9fbe3f5 upstream. Classic BPF programs have been identified as potential vectors for intra-mode Branch Target Injection (BTI) attacks. Classic BPF programs can be run by unprivileged users. They allow unprivileged code to execute inside the kernel. Attackers can use unprivileged cBPF to craft branch history in kernel mode that can influence the target of indirect branches. Introduce a branch history buffer (BHB) clearing sequence during the JIT compilation of classic BPF programs. The clearing sequence is the same as is used in previous mitigations to protect syscalls. Since eBPF programs already have their own mitigations in place, only insert the call on classic programs that aren't run by privileged users. Signed-off-by: Daniel Sneddon Signed-off-by: Pawan Gupta Signed-off-by: Dave Hansen Acked-by: Daniel Borkmann Reviewed-by: Alexandre Chartre Signed-off-by: Greg Kroah-Hartman commit 2176530849b1c373735b23663f80c8db166d4f99 Author: James Morse Date: Mon Aug 12 17:50:22 2024 +0100 arm64: proton-pack: Add new CPUs 'k' values for branch mitigation commit efe676a1a7554219eae0b0dcfe1e0cdcc9ef9aef upstream. Update the list of 'k' values for the branch mitigation from arm's website. Add the values for Cortex-X1C. The MIDR_EL1 value can be found here: https://developer.arm.com/documentation/101968/0002/Register-descriptions/AArch> Link: https://developer.arm.com/documentation/110280/2-0/?lang=en Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit e5f5100f1c64ac6c72671b2cf6b46542fce93706 Author: James Morse Date: Tue Apr 29 16:03:38 2025 +0100 arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users commit f300769ead032513a68e4a02e806393402e626f8 upstream. Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Acked-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit 38c345fd54afd9d6ed8d3fcddf3f6ea23887bf78 Author: James Morse Date: Thu Dec 9 15:13:24 2021 +0000 arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs commit 0dfefc2ea2f29ced2416017d7e5b1253a54c2735 upstream. A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Acked-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit f2aebb8ec64d11a66a1a739660fc552671997863 Author: James Morse Date: Tue Apr 29 13:55:17 2025 +0100 arm64: proton-pack: Expose whether the branchy loop k value commit a1152be30a043d2d4dcb1683415f328bf3c51978 upstream. Add a helper to expose the k value of the branchy loop. This is needed by the BPF JIT to generate the mitigation sequence in BPF programs. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit ec5bca57afc6bef581f800f8f9496f2ae1633271 Author: James Morse Date: Mon Aug 19 14:15:53 2024 +0100 arm64: proton-pack: Expose whether the platform is mitigated by firmware commit e7956c92f396a44eeeb6eaf7a5b5e1ad24db6748 upstream. is_spectre_bhb_fw_affected() allows the caller to determine if the CPU is known to need a firmware mitigation. CPUs are either on the list of CPUs we know about, or firmware has been queried and reported that the platform is affected - and mitigated by firmware. This helper is not useful to determine if the platform is mitigated by firmware. A CPU could be on the know list, but the firmware may not be implemented. Its affected but not mitigated. spectre_bhb_enable_mitigation() handles this distinction by checking the firmware state before enabling the mitigation. Add a helper to expose this state. This will be used by the BPF JIT to determine if calling firmware for a mitigation is necessary and supported. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 2a3915e86187ea8a48e7f899ec3fb000f8159fb6 Author: James Morse Date: Thu Dec 9 15:12:19 2021 +0000 arm64: insn: Add support for encoding DSB commit 63de8abd97ddb9b758bd8f915ecbd18e1f1a87a0 upstream. To generate code in the eBPF epilogue that uses the DSB instruction, insn.c needs a heler to encode the type and domain. Re-use the crm encoding logic from the DMB instruction. Signed-off-by: James Morse Reviewed-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 86b37810fa1e40b93171da023070b99ccbb4ea04 Author: Omar Sandoval Date: Fri Apr 25 01:51:24 2025 -0700 sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash commit bbce3de72be56e4b5f68924b7da9630cc89aa1a8 upstream. There is a code path in dequeue_entities() that can set the slice of a sched_entity to U64_MAX, which sometimes results in a crash. The offending case is when dequeue_entities() is called to dequeue a delayed group entity, and then the entity's parent's dequeue is delayed. In that case: 1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX. 2. The first for_each_sched_entity() loop dequeues the entity. 3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent. 4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_. 5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX. This throws off subsequent calculations with potentially catastrophic results. A manifestation we saw in production was: 6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number. 7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number. 8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number. 9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow. 11. Nothing appears to be eligible, so pick_eevdf() returns NULL. 12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes. Dumping the cfs_rq states from the core dumps with drgn showed tell-tale huge vruntime ranges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign" since the rest of the runqueue needed to be in a particular state to crash). Fix it in dequeue_entities() by always setting slice from the first non-empty cfs_rq. Fixes: aef6987d8954 ("sched/eevdf: Propagate min_slice up the cgroup hierarchy") Signed-off-by: Omar Sandoval Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/f0c2d1072be229e1bdddc73c0703919a8b00c652.1745570998.git.osandov@fb.com Signed-off-by: Greg Kroah-Hartman commit 16bae58f7355e3cf45a1cd72f8d1a9e9c2de9806 Author: Johannes Weiner Date: Mon Apr 7 14:01:53 2025 -0400 mm: page_alloc: speed up fallbacks in rmqueue_bulk() commit 90abee6d7895d5eef18c91d870d8168be4e76e9d upstream. The test robot identified c2f6ea38fc1b ("mm: page_alloc: don't steal single pages from biggest buddy") as the root cause of a 56.4% regression in vm-scalability::lru-file-mmap-read. Carlos reports an earlier patch, c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion"), as the root cause for a regression in worst-case zone->lock+irqoff hold times. Both of these patches modify the page allocator's fallback path to be less greedy in an effort to stave off fragmentation. The flip side of this is that fallbacks are also less productive each time around, which means the fallback search can run much more frequently. Carlos' traces point to rmqueue_bulk() specifically, which tries to refill the percpu cache by allocating a large batch of pages in a loop. It highlights how once the native freelists are exhausted, the fallback code first scans orders top-down for whole blocks to claim, then falls back to a bottom-up search for the smallest buddy to steal. For the next batch page, it goes through the same thing again. This can be made more efficient. Since rmqueue_bulk() holds the zone->lock over the entire batch, the freelists are not subject to outside changes; when the search for a block to claim has already failed, there is no point in trying again for the next page. Modify __rmqueue() to remember the last successful fallback mode, and restart directly from there on the next rmqueue_bulk() iteration. Oliver confirms that this improves beyond the regression that the test robot reported against c2f6ea38fc1b: commit: f3b92176f4 ("tools/selftests: add guard region test for /proc/$pid/pagemap") c2f6ea38fc ("mm: page_alloc: don't steal single pages from biggest buddy") acc4d5ff0b ("Merge tag 'net-6.15-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") 2c847f27c3 ("mm: page_alloc: speed up fallbacks in rmqueue_bulk()") <--- your patch f3b92176f4f7100f c2f6ea38fc1b640aa7a2e155cc1 acc4d5ff0b61eb1715c498b6536 2c847f27c37da65a93d23c237c5 ---------------- --------------------------- --------------------------- --------------------------- %stddev %change %stddev %change %stddev %change %stddev \ | \ | \ | \ 25525364 ± 3% -56.4% 11135467 -57.8% 10779336 +31.6% 33581409 vm-scalability.throughput Carlos confirms that worst-case times are almost fully recovered compared to before the earlier culprit patch: 2dd482ba627d (before freelist hygiene): 1ms c0cd6f557b90 (after freelist hygiene): 90ms next-20250319 (steal smallest buddy): 280ms this patch : 8ms [jackmanb@google.com: comment updates] Link: https://lkml.kernel.org/r/D92AC0P9594X.3BML64MUKTF8Z@google.com [hannes@cmpxchg.org: reset rmqueue_mode in rmqueue_buddy() error loop, per Yunsheng Lin] Link: https://lkml.kernel.org/r/20250409140023.GA2313@cmpxchg.org Link: https://lkml.kernel.org/r/20250407180154.63348-1-hannes@cmpxchg.org Fixes: c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion") Fixes: c2f6ea38fc1b ("mm: page_alloc: don't steal single pages from biggest buddy") Signed-off-by: Johannes Weiner Signed-off-by: Brendan Jackman Reported-by: kernel test robot Reported-by: Carlos Song Tested-by: Carlos Song Tested-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202503271547.fc08b188-lkp@intel.com Reviewed-by: Brendan Jackman Tested-by: Shivank Garg Acked-by: Zi Yan Reviewed-by: Vlastimil Babka Cc: [6.10+] Signed-off-by: Andrew Morton Signed-off-by: Johannes Weiner Signed-off-by: Greg Kroah-Hartman commit 564d25b1a6a08250ec86ab6c1e76f457c590a3fa Author: Johannes Weiner Date: Mon Feb 24 19:08:24 2025 -0500 mm: page_alloc: don't steal single pages from biggest buddy commit c2f6ea38fc1b640aa7a2e155cc1c0410ff91afa2 upstream. The fallback code searches for the biggest buddy first in an attempt to steal the whole block and encourage type grouping down the line. The approach used to be this: - Non-movable requests will split the largest buddy and steal the remainder. This splits up contiguity, but it allows subsequent requests of this type to fall back into adjacent space. - Movable requests go and look for the smallest buddy instead. The thinking is that movable requests can be compacted, so grouping is less important than retaining contiguity. c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion") enforces freelist type hygiene, which restricts stealing to either claiming the whole block or just taking the requested chunk; no additional pages or buddy remainders can be stolen any more. The patch mishandled when to switch to finding the smallest buddy in that new reality. As a result, it may steal the exact request size, but from the biggest buddy. This causes fracturing for no good reason. Fix this by committing to the new behavior: either steal the whole block, or fall back to the smallest buddy. Remove single-page stealing from steal_suitable_fallback(). Rename it to try_to_steal_block() to make the intentions clear. If this fails, always fall back to the smallest buddy. The following is from 4 runs of mmtest's thpchallenge. "Pollute" is single page fallback, "steal" is conversion of a partially used block. The numbers for free block conversions (omitted) are comparable. vanilla patched @pollute[unmovable from reclaimable]: 27 106 @pollute[unmovable from movable]: 82 46 @pollute[reclaimable from unmovable]: 256 83 @pollute[reclaimable from movable]: 46 8 @pollute[movable from unmovable]: 4841 868 @pollute[movable from reclaimable]: 5278 12568 @steal[unmovable from reclaimable]: 11 12 @steal[unmovable from movable]: 113 49 @steal[reclaimable from unmovable]: 19 34 @steal[reclaimable from movable]: 47 21 @steal[movable from unmovable]: 250 183 @steal[movable from reclaimable]: 81 93 The allocator appears to do a better job at keeping stealing and polluting to the first fallback preference. As a result, the numbers for "from movable" - the least preferred fallback option, and most detrimental to compactability - are down across the board. Link: https://lkml.kernel.org/r/20250225001023.1494422-2-hannes@cmpxchg.org Fixes: c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion") Signed-off-by: Johannes Weiner Suggested-by: Vlastimil Babka Reviewed-by: Brendan Jackman Reviewed-by: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Johannes Weiner Signed-off-by: Greg Kroah-Hartman commit 12abefb8c8210914c9b8618bf2f04ed8ed3c09d7 Author: Hao Qin Date: Sat Mar 15 10:27:30 2025 +0800 Bluetooth: btmtk: Remove the resetting step before downloading the fw commit 33634e2ab7c6369391e0ca4b9b97dc861e33d20e upstream. Remove the resetting step before downloading the fw, as it may cause other usb devices to fail to initialise when connected during boot on kernels 6.11 and newer. Signed-off-by: Hao Qin Signed-off-by: Luiz Augusto von Dentz Cc: "Geoffrey D. Bennett" Signed-off-by: Greg Kroah-Hartman commit c7a9df4ef4a774b75101d859fa9e755383e10157 Author: Hao Qin Date: Fri Jan 10 17:55:48 2025 +0800 Bluetooth: btmtk: Remove resetting mt7921 before downloading the fw commit a7208610761ae9b3bc109ddc493eb7c332fca5b2 upstream. Remove resetting mt7921 before downloading the fw, as it may cause command timeout when performing the reset. Signed-off-by: Hao Qin Signed-off-by: Luiz Augusto von Dentz Cc: "Geoffrey D. Bennett" Signed-off-by: Greg Kroah-Hartman commit 2482f7705b83cb440d11bdc0a75cd37ca66de6ef Author: Jens Axboe Date: Mon May 5 08:34:39 2025 -0600 io_uring: always arm linked timeouts prior to issue Commit b53e523261bf058ea4a518b482222e7a277b186b upstream. There are a few spots where linked timeouts are armed, and not all of them adhere to the pre-arm, attempt issue, post-arm pattern. This can be problematic if the linked request returns that it will trigger a callback later, and does so before the linked timeout is fully armed. Consolidate all the linked timeout handling into __io_issue_sqe(), rather than have it spread throughout the various issue entry points. Cc: stable@vger.kernel.org Link: https://github.com/axboe/liburing/issues/1390 Reported-by: Chase Hiltz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6b0383a21d3a6dfdc6b8294418d89cf5551755b3 Author: Miguel Ojeda Date: Fri May 2 16:02:37 2025 +0200 rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint commit 211dcf77856db64c73e0c3b9ce0c624ec855daca upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move back the `uninlined_format_args` to `style` from `pedantic` (it was there waiting for rust-analyzer suppotr), and thus we will start to see lints like: warning: variables can be used directly in the `format!` string --> rust/macros/kunit.rs:105:37 | 105 | let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 105 - let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); 105 + let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}"); There is even a case that is a pure removal: warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:51:13 | 51 | format!("{field}={content}\0", field = field, content = content) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 51 - format!("{field}={content}\0", field = field, content = content) 51 + format!("{field}={content}\0") The lints all seem like nice cleanups, thus just apply them. We may want to disable `allow-mixed-uninlined-format-args` in the future. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/14160 [1] Acked-by: Benno Lossin Reviewed-by: Tamir Duberstein Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 1c25723831c444affee78540eced1ceedfa4236b Author: Miguel Ojeda Date: Fri May 2 16:02:34 2025 +0200 rust: allow Rust 1.87.0's `clippy::ptr_eq` lint commit a39f3087092716f2bd531d6fdc20403c3dc2a879 upstream. Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand the `ptr_eq` lint, e.g.: error: use `core::ptr::eq` when comparing raw pointers --> rust/kernel/list.rs:438:12 | 438 | if self.first == item { | ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq = note: `-D clippy::ptr-eq` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]` It is expected that a PR to relax the lint will be backported [2] by the time Rust 1.87.0 releases, since the lint was considered too eager (at least by default) [3]. Thus allow the lint temporarily just in case. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/14339 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2] Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3] Link: https://lore.kernel.org/r/20250502140237.1659624-3-ojeda@kernel.org [ Converted to `allow`s since backport was confirmed. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 6aac2c54762c4b0b1cbd8c7ffa365283e171bf5d Author: Christian Lamparter Date: Fri May 9 11:50:39 2025 +0200 Revert "um: work around sched_yield not yielding in time-travel mode" This reverts commit da780c4a075ba2deb05ae29f0af4a990578c7901 which is commit 887c5c12e80c8424bd471122d2e8b6b462e12874 upstream. Reason being that the patch depends on at least commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not yield") in order to build. Otherwise it fails with: | /usr/bin/ld: arch/um/kernel/skas/syscall.o: in function `handle_syscall': | linux-6.12.27/arch/um/kernel/skas/syscall.c:43:(.text+0xa2): undefined | reference to `tt_extra_sched_jiffies' | collect2: error: ld returned 1 exit status The author Benjamin Berg commented: "I think it is better to just not backport commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not yield")" Link: https://lore.kernel.org/linux-um/8ce0b6056a9726e540f61bce77311278654219eb.camel@sipsolutions.net/ Cc: # 6.12.y Cc: Benjamin Berg Signed-off-by: Christian Lamparter Signed-off-by: Greg Kroah-Hartman commit cd010271a92b9c5e04901cdf630b0b92d25c3375 Author: Al Viro Date: Mon Apr 28 23:56:14 2025 -0400 do_umount(): add missing barrier before refcount checks in sync case [ Upstream commit 65781e19dcfcb4aed1167d87a3ffcc2a0c071d47 ] do_umount() analogue of the race fixed in 119e1ef80ecf "fix __legitimize_mnt()/mntput() race". Here we want to make sure that if __legitimize_mnt() doesn't notice our lock_mount_hash(), we will notice their refcount increment. Harder to hit than mntput_no_expire() one, fortunately, and consequences are milder (sync umount acting like umount -l on a rare race with RCU pathwalk hitting at just the wrong time instead of use-after-free galore mntput_no_expire() counterpart used to be hit). Still a bug... Fixes: 48a066e72d97 ("RCU'd vfsmounts") Reviewed-by: Christian Brauner Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 3edac2949eb594623bfddce57df080a4ee3ce868 Author: Gabriel Krisman Bertazi Date: Thu May 8 14:12:03 2025 -0400 io_uring/sqpoll: Increase task_work submission batch size [ Upstream commit 92835cebab120f8a5f023a26a792a2ac3f816c4f ] Our QA team reported a 10%-23%, throughput reduction on an io_uring sqpoll testcase doing IO to a null_blk, that I traced back to a reduction of the device submission queue depth utilization. It turns out that, after commit af5d68f8892f ("io_uring/sqpoll: manage task_work privately"), we capped the number of task_work entries that can be completed from a single spin of sqpoll to only 8 entries, before the sqpoll goes around to (potentially) sleep. While this cap doesn't drive the submission side directly, it impacts the completion behavior, which affects the number of IO queued by fio per sqpoll cycle on the submission side, and io_uring ends up seeing less ios per sqpoll cycle. As a result, block layer plugging is less effective, and we see more time spent inside the block layer in profilings charts, and increased submission latency measured by fio. There are other places that have increased overhead once sqpoll sleeps more often, such as the sqpoll utilization calculation. But, in this microbenchmark, those were not representative enough in perf charts, and their removal didn't yield measurable changes in throughput. The major overhead comes from the fact we plug less, and less often, when submitting to the block layer. My benchmark is: fio --ioengine=io_uring --direct=1 --iodepth=128 --runtime=300 --bs=4k \ --invalidate=1 --time_based --ramp_time=10 --group_reporting=1 \ --filename=/dev/nullb0 --name=RandomReads-direct-nullb-sqpoll-4k-1 \ --rw=randread --numjobs=1 --sqthread_poll In one machine, tested on top of Linux 6.15-rc1, we have the following baseline: READ: bw=4994MiB/s (5236MB/s), 4994MiB/s-4994MiB/s (5236MB/s-5236MB/s), io=439GiB (471GB), run=90001-90001msec With this patch: READ: bw=5762MiB/s (6042MB/s), 5762MiB/s-5762MiB/s (6042MB/s-6042MB/s), io=506GiB (544GB), run=90001-90001msec which is a 15% improvement in measured bandwidth. The average submission latency is noticeably lowered too. As measured by fio: Baseline: lat (usec): min=20, max=241, avg=99.81, stdev=3.38 Patched: lat (usec): min=26, max=226, avg=86.48, stdev=4.82 If we look at blktrace, we can also see the plugging behavior is improved. In the baseline, we end up limited to plugging 8 requests in the block layer regardless of the device queue depth size, while after patching we can drive more io, and we manage to utilize the full device queue. In the baseline, after a stabilization phase, an ordinary submission looks like: 254,0 1 49942 0.016028795 5977 U N [iou-sqp-5976] 7 After patching, I see consistently more requests per unplug. 254,0 1 4996 0.001432872 3145 U N [iou-sqp-3144] 32 Ideally, the cap size would at least be the deep enough to fill the device queue, but we can't predict that behavior, or assume all IO goes to a single device, and thus can't guess the ideal batch size. We also don't want to let the tw run unbounded, though I'm not sure it would really be a problem. Instead, let's just give it a more sensible value that will allow for more efficient batching. I've tested with different cap values, and initially proposed to increase the cap to 1024. Jens argued it is too big of a bump and I observed that, with 32, I'm no longer able to observe this bottleneck in any of my machines. Fixes: af5d68f8892f ("io_uring/sqpoll: manage task_work privately") Signed-off-by: Gabriel Krisman Bertazi Link: https://lore.kernel.org/r/20250508181203.3785544-1-krisman@suse.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 944af45bb76bf7492de6c1e6033c34e5198ccf0d Author: Tejas Upadhyay Date: Mon Apr 28 13:53:57 2025 +0530 drm/xe/tests/mocs: Hold XE_FORCEWAKE_ALL for LNCF regs [ Upstream commit 51c0ee84e4dc339287b2d7335f2b54d747794c83 ] LNCF registers report wrong values when XE_FORCEWAKE_GT only is held. Holding XE_FORCEWAKE_ALL ensures correct operations on LNCF regs. V2(Himal): - Use xe_force_wake_ref_has_domain Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1999 Fixes: a6a4ea6d7d37 ("drm/xe: Add mocs kunit") Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20250428082357.1730068-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 70a2585e582058e94fe4381a337be42dec800337) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 95a75ed2b005447f96fbd4ac61758ccda44069d1 Author: Himal Prasad Ghimiray Date: Mon Oct 14 13:25:47 2024 +0530 drm/xe/tests/mocs: Update xe_force_wake_get() return handling [ Upstream commit 6a966d677d06e96a81d430537abb5db65e2b4fda ] With xe_force_wake_get() now returning the refcount-incremented domain mask, a return value of 0 indicates failure for single domains. Change assert condition to incorporate this change in return and pass the return value to xe_force_wake_put() v3 - return xe_wakeref_t instead of int in xe_force_wake_get() v5 - return unsigned int for xe_force_wake_get() Cc: Rodrigo Vivi Cc: Lucas De Marchi Signed-off-by: Himal Prasad Ghimiray Reviewed-by: Nirmoy Das Reviewed-by: Badal Nilawar Link: https://patchwork.freedesktop.org/patch/msgid/20241014075601.2324382-13-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi Stable-dep-of: 51c0ee84e4dc ("drm/xe/tests/mocs: Hold XE_FORCEWAKE_ALL for LNCF regs") Signed-off-by: Sasha Levin commit d6b013b44e448383fc9ddc3d2fad5646e875cb73 Author: Clément Léger Date: Tue Apr 22 18:23:09 2025 +0200 riscv: misaligned: enable IRQs while handling misaligned accesses [ Upstream commit 453805f0a28fc5091e46145e6560c776f7c7a611 ] We can safely reenable IRQs if coming from userspace. This allows to access user memory that could potentially trigger a page fault. Fixes: b686ecdeacf6 ("riscv: misaligned: Restrict user access to kernel memory") Signed-off-by: Clément Léger Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250422162324.956065-3-cleger@rivosinc.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 45a0697ceeae242832b075da7aa4918417410563 Author: Clément Léger Date: Tue Apr 22 18:23:08 2025 +0200 riscv: misaligned: factorize trap handling [ Upstream commit fd94de9f9e7aac11ec659e386b9db1203d502023 ] Since both load/store and user/kernel should use almost the same path and that we are going to add some code around that, factorize it. Signed-off-by: Clément Léger Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250422162324.956065-2-cleger@rivosinc.com Signed-off-by: Alexandre Ghiti Stable-dep-of: 453805f0a28f ("riscv: misaligned: enable IRQs while handling misaligned accesses") Signed-off-by: Sasha Levin commit 19fa2a4830290de79b89ad8d39815b79d6521bfb Author: Daniel Wagner Date: Fri May 2 10:58:00 2025 +0200 nvme: unblock ctrl state transition for firmware update [ Upstream commit 650415fca0a97472fdd79725e35152614d1aad76 ] The original nvme subsystem design didn't have a CONNECTING state; the state machine allowed transitions from RESETTING to LIVE directly. With the introduction of nvme fabrics the CONNECTING state was introduce. Over time the nvme-pci started to use the CONNECTING state as well. Eventually, a bug fix for the nvme-fc started to depend that the only valid transition to LIVE was from CONNECTING. Though this change didn't update the firmware update handler which was still depending on RESETTING to LIVE transition. The simplest way to address it for the time being is to switch into CONNECTING state before going to LIVE state. Fixes: d2fe192348f9 ("nvme: only allow entering LIVE from CONNECTING state") Reported-by: Guenter Roeck Signed-off-by: Daniel Wagner Closes: https://lore.kernel.org/all/0134ea15-8d5f-41f7-9e9a-d7e6d82accaa@roeck-us.net Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7798edcc5b56ba3bfd3206fa528047aa37875ba8 Author: Kevin Baker Date: Mon May 5 12:02:56 2025 -0500 drm/panel: simple: Update timings for AUO G101EVN010 [ Upstream commit 7c6fa1797a725732981f2d77711c867166737719 ] Switch to panel timings based on datasheet for the AUO G101EVN01.0 LVDS panel. Default timings were tested on the panel. Previous mode-based timings resulted in horizontal display shift. Signed-off-by: Kevin Baker Fixes: 4fb86404a977 ("drm/panel: simple: Add AUO G101EVN010 panel support") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20250505170256.1385113-1-kevinb@ventureresearch.com Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250505170256.1385113-1-kevinb@ventureresearch.com Signed-off-by: Sasha Levin commit 184b147b9f7f07577567a80fcc9314f2bd0b0b00 Author: Lizhi Xu Date: Mon Apr 28 22:36:26 2025 +0800 loop: Add sanity check for read/write_iter [ Upstream commit f5c84eff634ba003326aa034c414e2a9dcb7c6a7 ] Some file systems do not support read_iter/write_iter, such as selinuxfs in this issue. So before calling them, first confirm that the interface is supported and then call it. It is releavant in that vfs_iter_read/write have the check, and removal of their used caused szybot to be able to hit this issue. Fixes: f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O") Reported-by: syzbot+6af973a3b8dfd2faefdc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6af973a3b8dfd2faefdc Signed-off-by: Lizhi Xu Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250428143626.3318717-1-lizhi.xu@windriver.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a781ffe410d83fa8092d30d53f583d0ce8732a7b Author: Christoph Hellwig Date: Fri Jan 31 13:00:38 2025 +0100 loop: factor out a loop_assign_backing_file helper [ Upstream commit d278164832618bf2775c6a89e6434e2633de1eed ] Split the code for setting up a backing file into a helper in preparation of adding more code to this path. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20250131120120.1315125-2-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: f5c84eff634b ("loop: Add sanity check for read/write_iter") Signed-off-by: Sasha Levin commit 5e1470b276729d5e871c759086d734ec6a85da86 Author: Christoph Hellwig Date: Fri Jan 10 06:47:18 2025 +0100 loop: refactor queue limits updates [ Upstream commit b38c8be255e89ffcdeb817407222d2de0b573a41 ] Replace loop_reconfigure_limits with a slightly less encompassing loop_update_limits that expects the caller to acquire and commit the queue limits to prepare for sorting out the freeze vs limits lock ordering. Signed-off-by: Christoph Hellwig Reviewed-by: Ming Lei Reviewed-by: Damien Le Moal Reviewed-by: Martin K. Petersen Reviewed-by: Johannes Thumshirn Reviewed-by: Nilay Shroff Link: https://lore.kernel.org/r/20250110054726.1499538-11-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: f5c84eff634b ("loop: Add sanity check for read/write_iter") Signed-off-by: Sasha Levin commit 0558ce095b767ab70e686f556f9adfb1805812fb Author: OGAWA Hirofumi Date: Tue Nov 19 23:42:23 2024 +0900 loop: Fix ABBA locking race [ Upstream commit b49125574cae26458d4aa02ce8f4523ba9a2a328 ] Current loop calls vfs_statfs() while holding the q->limits_lock. If FS takes some locking in vfs_statfs callback, this may lead to ABBA locking bug (at least, FAT fs has this issue actually). So this patch calls vfs_statfs() outside q->limits_locks instead, because looks like no reason to hold q->limits_locks while getting discord configs. Chain exists of: &sbi->fat_lock --> &q->q_usage_counter(io)#17 --> &q->limits_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->limits_lock); lock(&q->q_usage_counter(io)#17); lock(&q->limits_lock); lock(&sbi->fat_lock); *** DEADLOCK *** Reported-by: syzbot+a5d8c609c02f508672cc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a5d8c609c02f508672cc Reviewed-by: Ming Lei Signed-off-by: OGAWA Hirofumi Signed-off-by: Jens Axboe Stable-dep-of: f5c84eff634b ("loop: Add sanity check for read/write_iter") Signed-off-by: Sasha Levin commit 722f6dece719e5a18ec949f4774eda302ec6d68c Author: John Garry Date: Fri Nov 1 09:22:15 2024 +0000 loop: Simplify discard granularity calc [ Upstream commit d47de6ac8842327ae1c782670283450159c55d5b ] A bdev discard granularity is always at least SECTOR_SIZE, so don't check for a zero value. Suggested-by: Christoph Hellwig Signed-off-by: John Garry Link: https://lore.kernel.org/r/20241101092215.422428-1-john.g.garry@oracle.com Signed-off-by: Jens Axboe Stable-dep-of: f5c84eff634b ("loop: Add sanity check for read/write_iter") Signed-off-by: Sasha Levin commit 02a77b3020a2b8777ead56468e8f1421e640ebd6 Author: John Garry Date: Wed Oct 30 11:19:00 2024 +0000 loop: Use bdev limit helpers for configuring discard [ Upstream commit 8d3fd059dd289e6c322e5741ad56794bcce699a2 ] Instead of directly looking at the request_queue limits, use the bdev limits helpers, which is preferable. Signed-off-by: John Garry Link: https://lore.kernel.org/r/20241030111900.3981223-1-john.g.garry@oracle.com Signed-off-by: Jens Axboe Stable-dep-of: f5c84eff634b ("loop: Add sanity check for read/write_iter") Signed-off-by: Sasha Levin commit 126be03494f2f9d3352910885e28a0f89f2aa576 Author: Nylon Chen Date: Fri Apr 11 15:38:49 2025 +0800 riscv: misaligned: Add handling for ZCB instructions [ Upstream commit eb16b3727c05ed36420c90eca1e8f0e279514c1c ] Add support for the Zcb extension's compressed half-word instructions (C.LHU, C.LH, and C.SH) in the RISC-V misaligned access trap handler. Signed-off-by: Zong Li Signed-off-by: Nylon Chen Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250411073850.3699180-2-nylon.chen@sifive.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit eaa30e1d0ed229311c939e9f471f8e52632ae7b9 Author: Thorsten Blum Date: Sun Apr 27 13:34:24 2025 +0200 MIPS: Fix MAX_REG_OFFSET [ Upstream commit c44572e0cc13c9afff83fd333135a0aa9b27ba26 ] Fix MAX_REG_OFFSET to point to the last register in 'pt_regs' and not to the marker itself, which could allow regs_get_register() to return an invalid offset. Fixes: 40e084a506eb ("MIPS: Add uprobes support.") Suggested-by: Maciej W. Rozycki Signed-off-by: Thorsten Blum Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit fb98c9e584f4a1038e399cc331bff24700dd03ad Author: Jonathan Cameron Date: Sun Apr 13 11:34:26 2025 +0100 iio: adc: dln2: Use aligned_s64 for timestamp [ Upstream commit 5097eaae98e53f9ab9d35801c70da819b92ca907 ] Here the lack of marking allows the overall structure to not be sufficiently aligned resulting in misplacement of the timestamp in iio_push_to_buffers_with_timestamp(). Use aligned_s64 to force the alignment on all architectures. Fixes: 7c0299e879dd ("iio: adc: Add support for DLN2 ADC") Reported-by: David Lechner Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Reviewed-by: David Lechner Link: https://patch.msgid.link/20250413103443.2420727-4-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ef5d6a40968021edc05debd19fdf7a4ca5bd1b50 Author: Jonathan Cameron Date: Sun Apr 13 11:34:27 2025 +0100 iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64 [ Upstream commit 1bb942287e05dc4c304a003ea85e6dd9a5e7db39 ] The IIO ABI requires 64-bit aligned timestamps. In this case insufficient padding would have been added on architectures where an s64 is only 32-bit aligned. Use aligned_s64 to enforce the correct alignment. Fixes: 327a0eaf19d5 ("iio: accel: adxl355: Add triggered buffer support") Reported-by: David Lechner Reviewed-by: Nuno Sá Reviewed-by: David Lechner Link: https://patch.msgid.link/20250413103443.2420727-5-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit afe884959738067d68e17400f50c3795ab5fb85d Author: Andy Shevchenko Date: Tue Sep 3 20:59:04 2024 +0300 types: Complement the aligned types with signed 64-bit one [ Upstream commit e4ca0e59c39442546866f3dd514a3a5956577daf ] Some user may want to use aligned signed 64-bit type. Provide it for them. Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20240903180218.3640501-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron Stable-dep-of: 1bb942287e05 ("iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64") Signed-off-by: Sasha Levin commit 245e319019c60afb87b21c4f9fc948346d5408c0 Author: Jonathan Cameron Date: Sun Apr 13 11:34:36 2025 +0100 iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer. [ Upstream commit f79aeb6c631b57395f37acbfbe59727e355a714c ] The trick of using __aligned(IIO_DMA_MINALIGN) ensures that there is no overlap between buffers used for DMA and those used for driver state storage that are before the marking. It doesn't ensure anything above state variables found after the marking. Hence move this particular bit of state earlier in the structure. Fixes: 10897f34309b ("iio: temp: maxim_thermocouple: Fix alignment for DMA safety") Reviewed-by: David Lechner Link: https://patch.msgid.link/20250413103443.2420727-14-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e9bf391a9bcea5a19def62e211216d27937c5a71 Author: Lothar Rubusch Date: Sun Mar 9 19:35:15 2025 +0000 iio: accel: adxl367: fix setting odr for activity time update [ Upstream commit 38f67d0264929762e54ae5948703a21f841fe706 ] Fix setting the odr value to update activity time based on frequency derrived by recent odr, and not by obsolete odr value. The [small] bug: When _adxl367_set_odr() is called with a new odr value, it first writes the new odr value to the hardware register ADXL367_REG_FILTER_CTL. Second, it calls _adxl367_set_act_time_ms(), which calls adxl367_time_ms_to_samples(). Here st->odr still holds the old odr value. This st->odr member is used to derrive a frequency value, which is applied to update ADXL367_REG_TIME_ACT. Hence, the idea is to update activity time, based on possibilities and power consumption by the current ODR rate. Finally, when the function calls return, again in _adxl367_set_odr() the new ODR is assigned to st->odr. The fix: When setting a new ODR value is set to ADXL367_REG_FILTER_CTL, also ADXL367_REG_TIME_ACT should probably be updated with a frequency based on the recent ODR value and not the old one. Changing the location of the assignment to st->odr fixes this. Fixes: cbab791c5e2a5 ("iio: accel: add ADXL367 driver") Signed-off-by: Lothar Rubusch Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250309193515.2974-1-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a2ad060643a44783fd6f5f124f4731ba7249d362 Author: Dave Penkler Date: Fri May 2 09:09:41 2025 +0200 usb: usbtmc: Fix erroneous generic_read ioctl return commit 4e77d3ec7c7c0d9535ccf1138827cb9bb5480b9b upstream. wait_event_interruptible_timeout returns a long The return value was being assigned to an int causing an integer overflow when the remaining jiffies > INT_MAX which resulted in random error returns. Use a long return value, converting to the int ioctl return only on error. Fixes: bb99794a4792 ("usb: usbtmc: Add ioctl for vendor specific read") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250502070941.31819-4-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 207391377646974a992cef301f6681ba133c00be Author: Dave Penkler Date: Fri May 2 09:09:40 2025 +0200 usb: usbtmc: Fix erroneous wait_srq ioctl return commit a9747c9b8b59ab4207effd20eb91a890acb44e16 upstream. wait_event_interruptible_timeout returns a long The return was being assigned to an int causing an integer overflow when the remaining jiffies > INT_MAX resulting in random error returns. Use a long return value, converting to the int ioctl return only on error. Fixes: 739240a9f6ac ("usb: usbtmc: Add ioctl USBTMC488_IOCTL_WAIT_SRQ") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250502070941.31819-3-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 29e17737465c62c0b40b5cec43289147467f6eed Author: Dave Penkler Date: Fri May 2 09:09:39 2025 +0200 usb: usbtmc: Fix erroneous get_stb ioctl error returns commit cac01bd178d6a2a23727f138d647ce1a0e8a73a1 upstream. wait_event_interruptible_timeout returns a long The return was being assigned to an int causing an integer overflow when the remaining jiffies > INT_MAX resulting in random error returns. Use a long return value and convert to int ioctl return only on error. When the return value of wait_event_interruptible_timeout was <= INT_MAX the number of remaining jiffies was returned which has no meaning for the user. Return 0 on success. Reported-by: Michael Katzmann Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250502070941.31819-2-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9d90c283eac503f8b8b9cbacffa811cfc1910954 Author: Oliver Neukum Date: Wed Apr 30 15:48:10 2025 +0200 USB: usbtmc: use interruptible sleep in usbtmc_read commit 054c5145540e5ad5b80adf23a5e3e2fc281fb8aa upstream. usbtmc_read() calls usbtmc_generic_read() which uses interruptible sleep, but usbtmc_read() itself uses uninterruptble sleep for mutual exclusion between threads. That makes no sense. Both should use interruptible sleep. Fixes: 5b775f672cc99 ("USB: add USB test and measurement class driver") Cc: stable Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20250430134810.226015-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 5ad298d6d4aebe1229adba6427e417e89a5208d8 Author: Andrei Kuchynski Date: Thu Apr 24 08:44:29 2025 +0000 usb: typec: ucsi: displayport: Fix NULL pointer access commit 312d79669e71283d05c05cc49a1a31e59e3d9e0e upstream. This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal. Cc: stable Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Signed-off-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Link: https://lore.kernel.org/r/20250424084429.3220757-3-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman commit 3366a199483a247e6610fdc9c1de65df68624c7e Author: RD Babiera Date: Tue Apr 29 23:47:01 2025 +0000 usb: typec: tcpm: delay SNK_TRY_WAIT_DEBOUNCE to SRC_TRYWAIT transition commit e918d3959b5ae0e793b8f815ce62240e10ba03a4 upstream. This patch fixes Type-C Compliance Test TD 4.7.6 - Try.SNK DRP Connect SNKAS. The compliance tester moves into SNK_UNATTACHED during toggling and expects the PUT to apply Rp after tPDDebounce of detection. If the port is in SNK_TRY_WAIT_DEBOUNCE, it will move into SRC_TRYWAIT immediately and apply Rp. This violates TD 4.7.5.V.3, where the tester confirms that the PUT attaches Rp after the transitions to Unattached.SNK for tPDDebounce. Change the tcpm_set_state delay between SNK_TRY_WAIT_DEBOUNCE and SRC_TRYWAIT to tPDDebounce. Fixes: a0a3e04e6b2c ("staging: typec: tcpm: Check for Rp for tPDDebounce") Cc: stable Signed-off-by: RD Babiera Reviewed-by: Badhri Jagan Sridharan Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250429234703.3748506-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman commit 1c001b6ddeb7377512c27a95e6d1c0b9ba93f120 Author: Lukasz Czechowski Date: Fri Apr 25 17:18:06 2025 +0200 usb: misc: onboard_usb_dev: fix support for Cypress HX3 hubs commit 9f657a92805cfc98e11cf5da9e8f4e02ecff2260 upstream. The Cypress HX3 USB3.0 hubs use different PID values depending on the product variant. The comment in compatibles table is misleading, as the currently used PIDs (0x6504 and 0x6506 for USB 3.0 and USB 2.0, respectively) are defaults for the CYUSB331x, while CYUSB330x and CYUSB332x variants use different values. Based on the datasheet [1], update the compatible usb devices table to handle different types of the hub. The change also includes vendor mode PIDs, which are used by the hub in I2C Master boot mode, if connected EEPROM contains invalid signature or is blank. This allows to correctly boot the hub even if the EEPROM will have broken content. Number of vcc supplies and timing requirements are the same for all HX variants, so the platform driver's match table does not have to be extended. [1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-DataSheet-v22_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecb53f644b8 Table 9. PID Values Fixes: b43cd82a1a40 ("usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family") Cc: stable Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-1-4a76a474a010@thaumatec.com Signed-off-by: Greg Kroah-Hartman commit 08eca452a6489e9a414abbaa14c7b14a784cac05 Author: Jim Lin Date: Tue Apr 22 19:40:01 2025 +0800 usb: host: tegra: Prevent host controller crash when OTG port is used commit 732f35cf8bdfece582f6e4a9c659119036577308 upstream. When a USB device is connected to the OTG port, the tegra_xhci_id_work() routine transitions the PHY to host mode and calls xhci_hub_control() with the SetPortFeature command to enable port power. In certain cases, the XHCI controller may be in a low-power state when this operation occurs. If xhci_hub_control() is invoked while the controller is suspended, the PORTSC register may return 0xFFFFFFFF, indicating a read failure. This causes xhci_hc_died() to be triggered, leading to host controller shutdown. Example backtrace: [ 105.445736] Workqueue: events tegra_xhci_id_work [ 105.445747] dump_backtrace+0x0/0x1e8 [ 105.445759] xhci_hc_died.part.48+0x40/0x270 [ 105.445769] tegra_xhci_set_port_power+0xc0/0x240 [ 105.445774] tegra_xhci_id_work+0x130/0x240 To prevent this, ensure the controller is fully resumed before interacting with hardware registers by calling pm_runtime_get_sync() prior to the host mode transition and xhci_hub_control(). Fixes: f836e7843036 ("usb: xhci-tegra: Add OTG support") Cc: stable Signed-off-by: Jim Lin Signed-off-by: Wayne Chang Link: https://lore.kernel.org/r/20250422114001.126367-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman commit d1c8fa4c6edb0b8b1dd84349251ca090f93b8f38 Author: Prashanth K Date: Tue Apr 22 16:02:30 2025 +0530 usb: gadget: Use get_status callback to set remote wakeup capability commit 5977a58dd5a4865198b0204b998adb0f634abe19 upstream. Currently when the host sends GET_STATUS request for an interface, we use get_status callbacks to set/clear remote wakeup capability of that interface. And if get_status callback isn't present for that interface, then we assume its remote wakeup capability based on bmAttributes. Now consider a scenario, where we have a USB configuration with multiple interfaces (say ECM + ADB), here ECM is remote wakeup capable and as of now ADB isn't. And bmAttributes will indicate the device as wakeup capable. With the current implementation, when host sends GET_STATUS request for both interfaces, we will set FUNC_RW_CAP for both. This results in USB3 CV Chapter 9.15 (Function Remote Wakeup Test) failures as host expects remote wakeup from both interfaces. The above scenario is just an example, and the failure can be observed if we use configuration with any interface except ECM. Hence avoid configuring remote wakeup capability from composite driver based on bmAttributes, instead use get_status callbacks and let the function drivers decide this. Cc: stable Fixes: 481c225c4802 ("usb: gadget: Handle function suspend feature selector") Signed-off-by: Prashanth K Reviewed-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250422103231.1954387-3-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 43ae91f561de47465a6a10b8633dbf222f2706d5 Author: Wayne Chang Date: Fri Apr 18 16:12:28 2025 +0800 usb: gadget: tegra-xudc: ACK ST_RC after clearing CTRL_RUN commit 59820fde001500c167342257650541280c622b73 upstream. We identified a bug where the ST_RC bit in the status register was not being acknowledged after clearing the CTRL_RUN bit in the control register. This could lead to unexpected behavior in the USB gadget drivers. This patch resolves the issue by adding the necessary code to explicitly acknowledge ST_RC after clearing CTRL_RUN based on the programming sequence, ensuring proper state transition. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable Signed-off-by: Wayne Chang Link: https://lore.kernel.org/r/20250418081228.1194779-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 75f23e49add86a2ede5214dd03f3e3976197a880 Author: Prashanth K Date: Tue Apr 22 16:02:29 2025 +0530 usb: gadget: f_ecm: Add get_status callback commit 8e3820271c517ceb89ab7442656ba49fa23ee1d0 upstream. When host sends GET_STATUS to ECM interface, handle the request from the function driver. Since the interface is wakeup capable, set the corresponding bit, and set RW bit if the function is already armed for wakeup by the host. Cc: stable Fixes: 481c225c4802 ("usb: gadget: Handle function suspend feature selector") Signed-off-by: Prashanth K Reviewed-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250422103231.1954387-2-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit fae7f4460188f5a0b937dfbd318e31403119a3a9 Author: Pawel Laszczak Date: Fri Apr 25 05:55:40 2025 +0000 usb: cdnsp: fix L1 resume issue for RTL_REVISION_NEW_LPM version commit 8614ecdb1570e4fffe87ebdc62b613ed66f1f6a6 upstream. The controllers with rtl version larger than RTL_REVISION_NEW_LPM (0x00002700) has bug which causes that controller doesn't resume from L1 state. It happens if after receiving LPM packet controller starts transitioning to L1 and in this moment the driver force resuming by write operation to PORTSC.PLS. It's corner case and happens when write operation to PORTSC occurs during device delay before transitioning to L1 after transmitting ACK time (TL1TokenRetry). Forcing transition from L1->L0 by driver for revision larger than RTL_REVISION_NEW_LPM is not needed, so driver can simply fix this issue through block call of cdnsp_force_l0_go function. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB9538B55C3A6E71F9ED29E980DD842@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 88d92cffc9d9c8807d9a6aaa8a5235494636fc86 Author: Pawel Laszczak Date: Fri Apr 18 04:55:16 2025 +0000 usb: cdnsp: Fix issue with resuming from L1 commit 241e2ce88e5a494be7a5d44c0697592f1632fbee upstream. In very rare cases after resuming controller from L1 to L0 it reads registers before the clock UTMI have been enabled and as the result driver reads incorrect value. Most of registers are in APB domain clock but some of them (e.g. PORTSC) are in UTMI domain clock. After entering to L1 state the UTMI clock can be disabled. When controller transition from L1 to L0 the port status change event is reported and in interrupt runtime function driver reads PORTSC. During this read operation controller synchronize UTMI and APB domain but UTMI clock is still disabled and in result it reads 0xFFFFFFFF value. To fix this issue driver increases APB timeout value. The issue is platform specific and if the default value of APB timeout is not sufficient then this time should be set Individually for each platform. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/PH7PR07MB953846C57973E4DB134CAA71DDBF2@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit f6fdbe4d543bade58278cd2f309b2e818142fafb Author: Prashanth K Date: Tue Apr 22 16:02:31 2025 +0530 usb: dwc3: gadget: Make gadget_wakeup asynchronous commit 2372f1caeca433c4c01c2482f73fbe057f5168ce upstream. Currently gadget_wakeup() waits for U0 synchronously if it was called from func_wakeup(), this is because we need to send the function wakeup command soon after the link is active. And the call is made synchronous by polling DSTS continuosly for 20000 times in __dwc3_gadget_wakeup(). But it observed that sometimes the link is not active even after polling 20K times, leading to remote wakeup failures. Adding a small delay between each poll helps, but that won't guarantee resolution in future. Hence make the gadget_wakeup completely asynchronous. Since multiple interfaces can issue a function wakeup at once, add a new variable wakeup_pending_funcs which will indicate the functions that has issued func_wakup, this is represented in a bitmap format. If the link is in U3, dwc3_gadget_func_wakeup() will set the bit corresponding to interface_id and bail out. Once link comes back to U0, linksts_change irq is triggered, where the function wakeup command is sent based on bitmap. Cc: stable Fixes: 92c08a84b53e ("usb: dwc3: Add function suspend and function wakeup support") Signed-off-by: Prashanth K Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20250422103231.1954387-4-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d133023c9a3fd28d0d71d5e91b1bb6dee1f556a0 Author: Jan Kara Date: Thu Apr 24 15:45:13 2025 +0200 ocfs2: stop quota recovery before disabling quotas commit fcaf3b2683b05a9684acdebda706a12025a6927a upstream. Currently quota recovery is synchronized with unmount using sb->s_umount semaphore. That is however prone to deadlocks because flush_workqueue(osb->ocfs2_wq) called from umount code can wait for quota recovery to complete while ocfs2_finish_quota_recovery() waits for sb->s_umount semaphore. Grabbing of sb->s_umount semaphore in ocfs2_finish_quota_recovery() is only needed to protect that function from disabling of quotas from ocfs2_dismount_volume(). Handle this problem by disabling quota recovery early during unmount in ocfs2_dismount_volume() instead so that we can drop acquisition of sb->s_umount from ocfs2_finish_quota_recovery(). Link: https://lkml.kernel.org/r/20250424134515.18933-6-jack@suse.cz Fixes: 5f530de63cfc ("ocfs2: Use s_umount for quota recovery protection") Signed-off-by: Jan Kara Reported-by: Shichangkuo Reported-by: Murad Masimov Reviewed-by: Heming Zhao Tested-by: Heming Zhao Acked-by: Joseph Qi Cc: Changwei Ge Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fe3d752a7a10a99049f98d5a9468acb580c17588 Author: Jan Kara Date: Thu Apr 24 15:45:12 2025 +0200 ocfs2: implement handshaking with ocfs2 recovery thread commit 8f947e0fd595951460f5a6e1ac29baa82fa02eab upstream. We will need ocfs2 recovery thread to acknowledge transitions of recovery_state when disabling particular types of recovery. This is similar to what currently happens when disabling recovery completely, just more general. Implement the handshake and use it for exit from recovery. Link: https://lkml.kernel.org/r/20250424134515.18933-5-jack@suse.cz Fixes: 5f530de63cfc ("ocfs2: Use s_umount for quota recovery protection") Signed-off-by: Jan Kara Reviewed-by: Heming Zhao Tested-by: Heming Zhao Acked-by: Joseph Qi Cc: Changwei Ge Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Murad Masimov Cc: Shichangkuo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f96041a959f7f5a08ca284a295c9aa0547555961 Author: Jan Kara Date: Thu Apr 24 15:45:11 2025 +0200 ocfs2: switch osb->disable_recovery to enum commit c0fb83088f0cc4ee4706e0495ee8b06f49daa716 upstream. Patch series "ocfs2: Fix deadlocks in quota recovery", v3. This implements another approach to fixing quota recovery deadlocks. We avoid grabbing sb->s_umount semaphore from ocfs2_finish_quota_recovery() and instead stop quota recovery early in ocfs2_dismount_volume(). This patch (of 3): We will need more recovery states than just pure enable / disable to fix deadlocks with quota recovery. Switch osb->disable_recovery to enum. Link: https://lkml.kernel.org/r/20250424134301.1392-1-jack@suse.cz Link: https://lkml.kernel.org/r/20250424134515.18933-4-jack@suse.cz Fixes: 5f530de63cfc ("ocfs2: Use s_umount for quota recovery protection") Signed-off-by: Jan Kara Reviewed-by: Heming Zhao Tested-by: Heming Zhao Acked-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Murad Masimov Cc: Shichangkuo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1b3b9158521a50f79e0f9b5435a05822cf67d998 Author: Heming Zhao Date: Mon Apr 14 14:01:23 2025 +0800 ocfs2: fix the issue with discontiguous allocation in the global_bitmap commit bd1261b16d9131d79723d982d54295e7f309797a upstream. commit 4eb7b93e0310 ("ocfs2: improve write IO performance when fragmentation is high") introduced another regression. The following ocfs2-test case can trigger this issue: > discontig_runner.sh => activate_discontig_bg.sh => resv_unwritten: > ${RESV_UNWRITTEN_BIN} -f ${WORK_PLACE}/large_testfile -s 0 -l \ > $((${FILE_MAJOR_SIZE_M}*1024*1024)) In my env, test disk size (by "fdisk -l "): > 53687091200 bytes, 104857600 sectors. Above command is: > /usr/local/ocfs2-test/bin/resv_unwritten -f \ > /mnt/ocfs2/ocfs2-activate-discontig-bg-dir/large_testfile -s 0 -l \ > 53187969024 Error log: > [*] Reserve 50724M space for a LARGE file, reserve 200M space for future test. > ioctl error 28: "No space left on device" > resv allocation failed Unknown error -1 > reserve unwritten region from 0 to 53187969024. Call flow: __ocfs2_change_file_space //by ioctl OCFS2_IOC_RESVSP64 ocfs2_allocate_unwritten_extents //start:0 len:53187969024 while() + ocfs2_get_clusters //cpos:0, alloc_size:1623168 (cluster number) + ocfs2_extend_allocation + ocfs2_lock_allocators | + choose OCFS2_AC_USE_MAIN & ocfs2_cluster_group_search | + ocfs2_add_inode_data ocfs2_add_clusters_in_btree __ocfs2_claim_clusters ocfs2_claim_suballoc_bits + During the allocation of the final part of the large file (after ~47GB), no chain had the required contiguous bits_wanted. Consequently, the allocation failed. How to fix: When OCFS2 is encountering fragmented allocation, the file system should stop attempting bits_wanted contiguous allocation and instead provide the largest available contiguous free bits from the cluster groups. Link: https://lkml.kernel.org/r/20250414060125.19938-2-heming.zhao@suse.com Fixes: 4eb7b93e0310 ("ocfs2: improve write IO performance when fragmentation is high") Signed-off-by: Heming Zhao Reported-by: Gautham Ananthakrishna Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b76eaef983c783ca4bda5a40d68960d75cba5c06 Author: Borislav Petkov (AMD) Date: Mon Apr 14 11:59:33 2025 +0200 x86/microcode: Consolidate the loader enablement checking commit 5214a9f6c0f56644acb9d2cbb58facf1856d322b upstream. Consolidate the whole logic which determines whether the microcode loader should be enabled or not into a single function and call it everywhere. Well, almost everywhere - not in mk_early_pgtbl_32() because there the kernel is running without paging enabled and checking dis_ucode_ldr et al would require physical addresses and uglification of the code. But since this is 32-bit, the easier thing to do is to simply map the initrd unconditionally especially since that mapping is getting removed later anyway by zap_early_initrd_mapping() and avoid the uglification. In doing so, address the issue of old 486er machines without CPUID support, not booting current kernels. [ mingo: Fix no previous prototype for ‘microcode_loader_disabled’ [-Wmissing-prototypes] ] Fixes: 4c585af7180c1 ("x86/boot/32: Temporarily map initrd for microcode loading") Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://lore.kernel.org/r/CANpbe9Wm3z8fy9HbgS8cuhoj0TREYEEkBipDuhgkWFvqX0UoVQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit d63851049f412cdfadaeef7a7eaef5031d11c1e9 Author: Dmitry Antipov Date: Wed May 7 09:50:44 2025 +0300 module: ensure that kobject_put() is safe for module type kobjects commit a6aeb739974ec73e5217c75a7c008a688d3d5cf1 upstream. In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe. Reported-by: syzbot+7fb8a372e1f6add936dd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7fb8a372e1f6add936dd Fixes: 942e443127e9 ("module: Fix mod->mkobj.kobj potentially freed too early") Cc: stable@vger.kernel.org Suggested-by: Petr Pavlu Signed-off-by: Dmitry Antipov Link: https://lore.kernel.org/r/20250507065044.86529-1-dmantipov@yandex.ru Signed-off-by: Petr Pavlu Signed-off-by: Greg Kroah-Hartman commit d66a22f6a432a9dd376c9b365d7dc89bd416909c Author: Tom Lendacky Date: Thu May 8 12:24:10 2025 -0500 memblock: Accept allocated memory before use in memblock_double_array() commit da8bf5daa5e55a6af2b285ecda460d6454712ff4 upstream. When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Mitigate this by calling accept_memory() on the memory range returned before the slab is available. Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12. Cc: stable@vger.kernel.org # see patch description, needs adjustments for <= 6.11 Fixes: dcdfdd40fa82 ("mm: Add support for unaccepted memory") Signed-off-by: Tom Lendacky Link: https://lore.kernel.org/r/da1ac73bf4ded761e21b4e4bb5178382a580cd73.1746725050.git.thomas.lendacky@amd.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Greg Kroah-Hartman commit ed45af6841a9abc20eb706e7bbd0c4aad8f6bb36 Author: Sebastian Andrzej Siewior Date: Fri Apr 4 15:31:16 2025 +0200 clocksource/i8253: Use raw_spinlock_irqsave() in clockevent_i8253_disable() commit 94cff94634e506a4a44684bee1875d2dbf782722 upstream. On x86 during boot, clockevent_i8253_disable() can be invoked via x86_late_time_init -> hpet_time_init() -> pit_timer_init() which happens with enabled interrupts. If some of the old i8253 hardware is actually used then lockdep will notice that i8253_lock is used in hard interrupt context. This causes lockdep to complain because it observed the lock being acquired with interrupts enabled and in hard interrupt context. Make clockevent_i8253_disable() acquire the lock with raw_spinlock_irqsave() to cure this. [ tglx: Massage change log and use guard() ] Fixes: c8c4076723dac ("x86/timer: Skip PIT initialization on modern chipsets") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20250404133116.p-XRWJXf@linutronix.de Signed-off-by: Greg Kroah-Hartman commit abbc99e898e4f4df254d3141993f0b48ad8673a6 Author: Yeoreum Yun Date: Fri May 2 19:04:12 2025 +0100 arm64: cpufeature: Move arm64_use_ng_mappings to the .data section to prevent wrong idmap generation commit 363cd2b81cfdf706bbfc9ec78db000c9b1ecc552 upstream. The PTE_MAYBE_NG macro sets the nG page table bit according to the value of "arm64_use_ng_mappings". This variable is currently placed in the .bss section. create_init_idmap() is called before the .bss section initialisation which is done in early_map_kernel(). Therefore, data/test_prot in create_init_idmap() could be set incorrectly through the PAGE_KERNEL -> PROT_DEFAULT -> PTE_MAYBE_NG macros. # llvm-objdump-21 --syms vmlinux-gcc | grep arm64_use_ng_mappings ffff800082f242a8 g O .bss 0000000000000001 arm64_use_ng_mappings The create_init_idmap() function disassembly compiled with llvm-21: // create_init_idmap() ffff80008255c058: d10103ff sub sp, sp, #0x40 ffff80008255c05c: a9017bfd stp x29, x30, [sp, #0x10] ffff80008255c060: a90257f6 stp x22, x21, [sp, #0x20] ffff80008255c064: a9034ff4 stp x20, x19, [sp, #0x30] ffff80008255c068: 910043fd add x29, sp, #0x10 ffff80008255c06c: 90003fc8 adrp x8, 0xffff800082d54000 ffff80008255c070: d280e06a mov x10, #0x703 // =1795 ffff80008255c074: 91400409 add x9, x0, #0x1, lsl #12 // =0x1000 ffff80008255c078: 394a4108 ldrb w8, [x8, #0x290] ------------- (1) ffff80008255c07c: f2e00d0a movk x10, #0x68, lsl #48 ffff80008255c080: f90007e9 str x9, [sp, #0x8] ffff80008255c084: aa0103f3 mov x19, x1 ffff80008255c088: aa0003f4 mov x20, x0 ffff80008255c08c: 14000000 b 0xffff80008255c08c <__pi_create_init_idmap+0x34> ffff80008255c090: aa082d56 orr x22, x10, x8, lsl #11 -------- (2) Note (1) is loading the arm64_use_ng_mappings value in w8 and (2) is set the text or data prot with the w8 value to set PTE_NG bit. If the .bss section isn't initialized, x8 could include a garbage value and generate an incorrect mapping. Annotate arm64_use_ng_mappings as __read_mostly so that it is placed in the .data section. Fixes: 84b04d3e6bdb ("arm64: kernel: Create initial ID map from C code") Cc: stable@vger.kernel.org # 6.9.x Tested-by: Nathan Chancellor Signed-off-by: Yeoreum Yun Link: https://lore.kernel.org/r/20250502180412.3774883-1-yeoreum.yun@arm.com [catalin.marinas@arm.com: use __read_mostly instead of __ro_after_init] [catalin.marinas@arm.com: slight tweaking of the code comment] Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 55701e992b179345929cfa8e8c4b9bc87170d1b3 Author: Jacek Lawrynowicz Date: Fri Apr 25 11:28:22 2025 +0200 accel/ivpu: Increase state dump msg timeout commit c4eb2f88d2796ab90c5430e11c48709716181364 upstream. Increase JMS message state dump command timeout to 100 ms. On some platforms, the FW may take a bit longer than 50 ms to dump its state to the log buffer and we don't want to miss any debug info during TDR. Fixes: 5e162f872d7a ("accel/ivpu: Add FW state dump on TDR") Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Jeff Hugo Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250425092822.2194465-1-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8e9c8a0393b5f85f1820c565ab8105660f4e8f92 Author: Jason Andryuk Date: Tue May 6 17:09:33 2025 -0400 xenbus: Use kref to track req lifetime commit 1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27 upstream. Marek reported seeing a NULL pointer fault in the xenbus_thread callstack: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems like it was xs_wake_up() in this case. It seems like req may have woken up the xs_wait_for_reply(), which kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed data. Linux Device Drivers 2nd edition states: "Normally, a wake_up call can cause an immediate reschedule to happen, meaning that other processes might run before wake_up returns." ... which would match the behaviour observed. Change to keeping two krefs on each request. One for the caller, and one for xenbus_thread. Each will kref_put() when finished, and the last will free it. This use of kref matches the description in Documentation/core-api/kref.rst Link: https://lore.kernel.org/xen-devel/ZO0WrR5J0xuwDIxW@mail-itl/ Reported-by: Marek Marczykowski-Górecki Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") Cc: stable@vger.kernel.org Signed-off-by: Jason Andryuk Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20250506210935.5607-1-jason.andryuk@amd.com> Signed-off-by: Greg Kroah-Hartman commit 54dd5d6af70570153b21c2281310600327695440 Author: John Ernberg Date: Fri May 2 11:40:55 2025 +0000 xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it commit cd9c058489053e172a6654cad82ee936d1b09fab upstream. Xen swiotlb support was missed when the patch set starting with 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN") was merged. When running Xen on iMX8QXP, a SoC without IOMMU, the effect was that USB transfers ended up corrupted when there was more than one URB inflight at the same time. Add a call to dma_kmalloc_needs_bounce() to make sure that allocations too small for DMA get bounced via swiotlb. Closes: https://lore.kernel.org/linux-usb/ab2776f0-b838-4cf6-a12a-c208eb6aad59@actia.se/ Fixes: 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN") Cc: stable@kernel.org # v6.5+ Signed-off-by: John Ernberg Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Message-ID: <20250502114043.1968976-2-john.ernberg@actia.se> Signed-off-by: Greg Kroah-Hartman commit 571dcf3d27b24800c171aea7b5e04ff06d10e2e9 Author: Paul Aurich Date: Tue May 6 22:28:09 2025 -0700 smb: client: Avoid race in open_cached_dir with lease breaks commit 3ca02e63edccb78ef3659bebc68579c7224a6ca2 upstream. A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs. Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked. Cc: stable@vger.kernel.org Reviewed-by: Henrique Carvalho Signed-off-by: Paul Aurich Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a9f28dbfdd1e606295f32a3ae6de47965f401243 Author: Alexey Charkov Date: Fri Apr 25 18:11:11 2025 +0400 usb: uhci-platform: Make the clock really optional commit a5c7973539b010874a37a0e846e62ac6f00553ba upstream. Device tree bindings state that the clock is optional for UHCI platform controllers, and some existing device trees don't provide those - such as those for VIA/WonderMedia devices. The driver however fails to probe now if no clock is provided, because devm_clk_get returns an error pointer in such case. Switch to devm_clk_get_optional instead, so that it could probe again on those platforms where no clocks are given. Cc: stable Fixes: 26c502701c52 ("usb: uhci: Add clk support to uhci-platform") Signed-off-by: Alexey Charkov Link: https://lore.kernel.org/r/20250425-uhci-clock-optional-v1-1-a1d462592f29@gmail.com Signed-off-by: Greg Kroah-Hartman commit 92d0a28afba2166801ed563a72aed37cb8ea27f7 Author: Alex Deucher Date: Wed Apr 30 12:50:02 2025 -0400 drm/amdgpu/hdp7: use memcfg register to post the write for HDP flush commit 5a11a2767731139bf87e667331aa2209e33a1d19 upstream. Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: 689275140cb8 ("drm/amdgpu/hdp7.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit dbc064adfcf9095e7d895bea87b2f75c1ab23236) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit df044182621ae2632e89d054835ddf23f64e24a5 Author: Alex Deucher Date: Wed Apr 30 12:48:51 2025 -0400 drm/amdgpu/hdp6: use memcfg register to post the write for HDP flush commit ca28e80abe4219c8f1a2961ae05102d70af6dc87 upstream. Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: abe1cbaec6cf ("drm/amdgpu/hdp6.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 84141ff615951359c9a99696fd79a36c465ed847) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0a776c305435e24ad0f52dc142b7822bd862de95 Author: Alex Deucher Date: Wed Apr 30 12:46:56 2025 -0400 drm/amdgpu/hdp5: use memcfg register to post the write for HDP flush commit 0e33e0f339b91eecd9558311449a3d1e728722d4 upstream. Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: cf424020e040 ("drm/amdgpu/hdp5.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit a5cb344033c7598762e89255e8ff52827abb57a4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b6f0f3e6c7a901c4bc7b5198276f9c96e0e8200a Author: Alex Deucher Date: Wed Apr 30 12:47:37 2025 -0400 drm/amdgpu/hdp5.2: use memcfg register to post the write for HDP flush commit dbc988c689333faeeed44d5561f372ff20395304 upstream. Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: f756dbac1ce1 ("drm/amdgpu/hdp5.2: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 4a89b7698e771914b4d5b571600c76e2fdcbe2a9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4872de413e20a9e151e8cca0f9f4603c056ee1be Author: Alex Deucher Date: Wed Apr 30 12:45:04 2025 -0400 drm/amdgpu/hdp4: use memcfg register to post the write for HDP flush commit f690e3974755a650259a45d71456decc9c96a282 upstream. Reading back the remapped HDP flush register seems to cause problems on some platforms. All we need is a read, so read back the memcfg register. Fixes: c9b8dcabb52a ("drm/amdgpu/hdp4.0: do a posting read when flushing HDP") Reported-by: Alexey Klimov Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher (cherry picked from commit 5c937b4a6050316af37ef214825b6340b5e9e391) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a13f9ac569f08ad2f0078bf90bd163c379ddde16 Author: Wayne Lin Date: Sun Apr 20 17:50:03 2025 +0800 drm/amd/display: Copy AUX read reply data whenever length > 0 commit 3924f45d4de7250a603fd7b50379237a6a0e5adf upstream. [Why] amdgpu_dm_process_dmub_aux_transfer_sync() should return all exact data reply from the sink side. Don't do the analysis job in it. [How] Remove unnecessary check condition AUX_TRANSACTION_REPLY_AUX_ACK. Fixes: ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Ray Wu Signed-off-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 9b540e3fe6796fec4fb1344f3be8952fc2f084d4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2d63e66f7ba7b88b87e72155a33b970c81cf4664 Author: Wayne Lin Date: Sun Apr 20 19:22:14 2025 +0800 drm/amd/display: Fix wrong handling for AUX_DEFER case commit 65924ec69b29296845c7f628112353438e63ea56 upstream. [Why] We incorrectly ack all bytes get written when the reply actually is defer. When it's defer, means sink is not ready for the request. We should retry the request. [How] Only reply all data get written when receive I2C_ACK|AUX_ACK. Otherwise, reply the number of actual written bytes received from the sink. Add some messages to facilitate debugging as well. Fixes: ad6756b4d773 ("drm/amd/display: Shift dc link aux to aux_payload") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Ray Wu Signed-off-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 3637e457eb0000bc37d8bbbec95964aad2fb29fd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0e225bdba360d95ce27b54bcfc47d7b502f8910f Author: Wayne Lin Date: Sun Apr 20 16:56:54 2025 +0800 drm/amd/display: Remove incorrect checking in dmub aux handler commit 396dc51b3b7ea524bf8061f478332d0039e96d5d upstream. [Why & How] "Request length != reply length" is expected behavior defined in spec. It's not an invalid reply. Besides, replied data handling logic is not designed to be written in amdgpu_dm_process_dmub_aux_transfer_sync(). Remove the incorrectly handling section. Fixes: ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Ray Wu Signed-off-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 81b5c6fa62af62fe89ae9576f41aae37830b94cb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fc7ac4ad1d160c14f179c99bf63ec7e41f8cfa3e Author: Wayne Lin Date: Sun Apr 20 16:29:07 2025 +0800 drm/amd/display: Fix the checking condition in dmub aux handling commit bc70e11b550d37fbd9eaed0f113ba560894f1609 upstream. [Why & How] Fix the checking condition for detecting AUX_RET_ERROR_PROTOCOL_ERROR. It was wrongly checking by "not equals to" Reviewed-by: Ray Wu Signed-off-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 1db6c9e9b62e1a8912f0a281c941099fca678da3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 468034a06a6e8043c5b50f9cd0cac730a6e497b5 Author: Aurabindo Pillai Date: Wed Apr 16 11:26:54 2025 -0400 drm/amd/display: more liberal vmin/vmax update for freesync commit f1c6be3999d2be2673a51a9be0caf9348e254e52 upstream. [Why] FAMS2 expects vmin/vmax to be updated in the case when freesync is off, but supported. But we only update it when freesync is enabled. [How] Change the vsync handler such that dc_stream_adjust_vmin_vmax() its called irrespective of whether freesync is enabled. If freesync is supported, then there is no harm in updating vmin/vmax registers. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3546 Reviewed-by: ChiaHsuan Chung Signed-off-by: Aurabindo Pillai Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d8c4afe78385cd355e4d80299d785379d6e874df Author: Roman Li Date: Mon Apr 14 12:56:48 2025 -0400 drm/amd/display: Fix invalid context error in dml helper commit 9984db63742099ee3f3cff35cf71306d10e64356 upstream. [Why] "BUG: sleeping function called from invalid context" error. after: "drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()" The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag for memory allocation, which shouldn't be used in atomic contexts. The allocation is needed only for using another helper function get_scaler_data_for_plane(). [How] Modify helpers to pass a pointer to scaler_data within existing context, eliminating the need for dynamic memory allocation/deallocation and copying. Fixes: 366e77cd4923 ("drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()") Reviewed-by: Aurabindo Pillai Signed-off-by: Roman Li Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 19323f414baa8155abcf7246bd0e04bfc01dc326 Author: Ruijing Dong Date: Fri May 2 11:19:26 2025 -0400 drm/amdgpu/vcn: using separate VCN1_AON_SOC offset commit b7e84fb708392b37e5dbb2a95db9b94a0e3f0aa2 upstream. VCN1_AON_SOC_ADDRESS_3_0 offset varies on different VCN generations, the issue in vcn4.0.5 is caused by a different VCN1_AON_SOC_ADDRESS_3_0 offset. This patch does the following: 1. use the same offset for other VCN generations. 2. use the vcn4.0.5 special offset 3. update vcn_4_0 and vcn_5_0 Acked-by: Saleemkhan Jamadar Reviewed-by: Leo Liu Signed-off-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 5c89ceda9984498b28716944633a9a01cbb2c90d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 206569cbf71ad14bb7aa06471385ab568bb8eafb Author: Matthew Brost Date: Tue Apr 8 08:59:15 2025 -0700 drm/xe: Add page queue multiplier commit 391008f34e711253c5983b0bf52277cc43723127 upstream. For an unknown reason the math to determine the PF queue size does is not correct - compute UMD applications are overflowing the PF queue which is fatal. A multippier of 8 fixes the problem. Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Jagmeet Randhawa Link: https://lore.kernel.org/r/20250408155915.78770-1-matthew.brost@intel.com (cherry picked from commit 29582e0ea75c95668d168b12406e3c56cf5a73c4) Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit a5f162727b91e480656da1876247a91f651f76de Author: Maíra Canal Date: Wed Apr 30 17:51:52 2025 -0300 drm/v3d: Add job to pending list if the reset was skipped commit 35e4079bf1a2570abffce6ababa631afcf8ea0e5 upstream. When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout. Cc: stable@vger.kernel.org # 6.0 Reported-by: Daivik Bhatia Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12227 [1] Closes: https://github.com/raspberrypi/linux/issues/6817 [2] Reviewed-by: Iago Toral Quiroga Acked-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20250430210643.57924-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit dadf9116108315f2eb14c7415c7805f392c476b4 Author: Silvano Seva Date: Tue Mar 11 09:49:49 2025 +0100 iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo commit 8114ef86e2058e2554111b793596f17bee23fa15 upstream. Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Fixes: 801a6e0af0c6 ("iio: imu: st_lsm6dsx: add support to LSM6DSO") Signed-off-by: Silvano Seva Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250311085030.3593-4-s.seva@4sigma.it Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a1cad8a3bca41dead9980615d35efc7bff1fd534 Author: Silvano Seva Date: Tue Mar 11 09:49:47 2025 +0100 iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo commit 159ca7f18129834b6f4c7eae67de48e96c752fc9 upstream. Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Silvano Seva Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250311085030.3593-2-s.seva@4sigma.it Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 82f6334a0b3e6577bf4d1df5cbdba35451c4502e Author: David Lechner Date: Thu Apr 17 11:52:39 2025 -0500 iio: imu: inv_mpu6050: align buffer for timestamp commit 1d2d8524eaffc4d9a116213520d2c650e07c9cc6 upstream. Align the buffer used with iio_push_to_buffers_with_timestamp() to ensure the s64 timestamp is aligned to 8 bytes. Fixes: 0829edc43e0a ("iio: imu: inv_mpu6050: read the full fifo when processing data") Signed-off-by: David Lechner Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-7-eafac1e22318@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c4dfff960b34d547ebd34bd5984b1960b0553c86 Author: Gabriel Shahrouzi Date: Mon Apr 21 09:15:39 2025 -0400 iio: adis16201: Correct inclinometer channel resolution commit 609bc31eca06c7408e6860d8b46311ebe45c1fef upstream. The inclinometer channels were previously defined with 14 realbits. However, the ADIS16201 datasheet states the resolution for these output channels is 12 bits (Page 14, text description; Page 15, table 7). Correct the realbits value to 12 to accurately reflect the hardware. Fixes: f7fe1d1dd5a5 ("staging: iio: new adis16201 driver") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/20250421131539.912966-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4cbd37a12aedd65d4c30db22fcb0131839f0c2da Author: Simon Xue Date: Wed Mar 12 14:20:16 2025 +0800 iio: adc: rockchip: Fix clock initialization sequence commit 839f81de397019f55161c5982d670ac19d836173 upstream. clock_set_rate should be executed after devm_clk_get_enabled. Fixes: 97ad10bb2901 ("iio: adc: rockchip_saradc: Make use of devm_clk_get_enabled") Signed-off-by: Simon Xue Reviewed-by: Heiko Stuebner Link: https://patch.msgid.link/20250312062016.137821-1-xxm@rock-chips.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c9f8413b78f2bcc69ce7650bf935bac0fdd7062f Author: Angelo Dureghello Date: Fri Apr 18 20:37:53 2025 +0200 iio: adc: ad7606: fix serial register access commit f083f8a21cc785ebe3a33f756a3fa3660611f8db upstream. Fix register read/write routine as per datasheet. When reading multiple consecutive registers, only the first one is read properly. This is due to missing chip select deassert and assert again between first and second 16bit transfer, as shown in the datasheet AD7606C-16, rev 0, figure 110. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Reviewed-by: David Lechner Signed-off-by: Angelo Dureghello Link: https://patch.msgid.link/20250418-wip-bl-ad7606-fix-reg-access-v3-1-d5eeb440c738@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7f37e31483681087cddbb0dbb14eafa730a002f8 Author: Jens Axboe Date: Wed May 7 07:34:24 2025 -0600 io_uring: ensure deferred completions are flushed for multishot commit 687b2bae0efff9b25e071737d6af5004e6e35af5 upstream. Multishot normally uses io_req_post_cqe() to post completions, but when stopping it, it may finish up with a deferred completion. This is fine, except if another multishot event triggers before the deferred completions get flushed. If this occurs, then CQEs may get reordered in the CQ ring, as new multishot completions get posted before the deferred ones are flushed. This can cause confusion on the application side, if strict ordering is required for the use case. When multishot posting via io_req_post_cqe(), flush any pending deferred completions first, if any. Cc: stable@vger.kernel.org # 6.1+ Reported-by: Norman Maurer Reported-by: Christian Mazakas Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4d41b9e4c9e80b38f2d729d8da852723b864a150 Author: Wayne Lin Date: Fri Apr 18 16:31:59 2025 +0800 drm/amd/display: Shift DMUB AUX reply command if necessary commit 5a3846648c0523fd850b7f0aec78c0139453ab8b upstream. [Why] Defined value of dmub AUX reply command field get updated but didn't adjust dm receiving side accordingly. [How] Check the received reply command value to see if it's updated version or not. Adjust it if necessary. Fixes: ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer") Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Ray Wu Signed-off-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d5c9ade755a9afa210840708a12a8f44c0d532f4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d362b21fefcef7eda8f1cd78a5925735d2b3287c Author: Mikhail Lobanov Date: Mon Apr 14 20:12:06 2025 +0300 KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception commit a2620f8932fa9fdabc3d78ed6efb004ca409019f upstream. Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM). This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault The issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do _something_ sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI. So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: Mikhail Lobanov Link: https://lore.kernel.org/r/20250414171207.155121-1-m.lobanov@rosa.ru [sean: massage changelog, make it clear this isn't architectural behavior] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 5156f7c484ab75862224465333649cf2070edad2 Author: Nysal Jan K.A. Date: Mon Apr 28 18:49:35 2025 +0530 selftests/mm: fix a build failure on powerpc commit 8cf6ecb18baac867585fe1cba5dde6dbf3b6d29a upstream. The compiler is unaware of the size of code generated by the ".rept" assembler directive. This results in the compiler emitting branch instructions where the offset to branch to exceeds the maximum allowed value, resulting in build failures like the following: CC protection_keys /tmp/ccypKWAE.s: Assembler messages: /tmp/ccypKWAE.s:2073: Error: operand out of range (0x0000000000020158 is not between 0xffffffffffff8000 and 0x0000000000007ffc) /tmp/ccypKWAE.s:2509: Error: operand out of range (0x0000000000020130 is not between 0xffffffffffff8000 and 0x0000000000007ffc) Fix the issue by manually adding nop instructions using the preprocessor. Link: https://lkml.kernel.org/r/20250428131937.641989-2-nysal@linux.ibm.com Fixes: 46036188ea1f ("selftests/mm: build with -O2") Reported-by: Madhavan Srinivasan Signed-off-by: Nysal Jan K.A. Tested-by: Venkat Rao Bagalkote Reviewed-by: Donet Tom Tested-by: Donet Tom Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b21ec0726a7b813c9a6cd757bb4225f7bdf8704c Author: Feng Tang Date: Wed Apr 23 18:36:45 2025 +0800 selftests/mm: compaction_test: support platform with huge mount of memory commit ab00ddd802f80e31fc9639c652d736fe3913feae upstream. When running mm selftest to verify mm patches, 'compaction_test' case failed on an x86 server with 1TB memory. And the root cause is that it has too much free memory than what the test supports. The test case tries to allocate 100000 huge pages, which is about 200 GB for that x86 server, and when it succeeds, it expects it's large than 1/3 of 80% of the free memory in system. This logic only works for platform with 750 GB ( 200 / (1/3) / 80% ) or less free memory, and may raise false alarm for others. Fix it by changing the fixed page number to self-adjustable number according to the real number of free memory. Link: https://lkml.kernel.org/r/20250423103645.2758-1-feng.tang@linux.alibaba.com Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") Signed-off-by: Feng Tang Acked-by: Dev Jain Reviewed-by: Baolin Wang Tested-by: Baolin Wang Cc: Shuah Khan Cc: Sri Jayaramappa Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b543a5a73b5cec4fa2c3996624d6428884fc677f Author: Peter Xu Date: Thu Apr 24 17:57:28 2025 -0400 mm/userfaultfd: fix uninitialized output field for -EAGAIN race commit 95567729173e62e0e60a1f8ad9eb2e1320a8ccac upstream. While discussing some userfaultfd relevant issues recently, Andrea noticed a potential ABI breakage with -EAGAIN on almost all userfaultfd ioctl()s. Quote from Andrea, explaining how -EAGAIN was processed, and how this should fix it (taking example of UFFDIO_COPY ioctl): The "mmap_changing" and "stale pmd" conditions are already reported as -EAGAIN written in the copy field, this does not change it. This change removes the subnormal case that left copy.copy uninitialized and required apps to explicitly set the copy field to get deterministic behavior (which is a requirement contrary to the documentation in both the manpage and source code). In turn there's no alteration to backwards compatibility as result of this change because userland will find the copy field consistently set to -EAGAIN, and not anymore sometime -EAGAIN and sometime uninitialized. Even then the change only can make a difference to non cooperative users of userfaultfd, so when UFFD_FEATURE_EVENT_* is enabled, which is not true for the vast majority of apps using userfaultfd or this unintended uninitialized field may have been noticed sooner. Meanwhile, since this bug existed for years, it also almost affects all ioctl()s that was introduced later. Besides UFFDIO_ZEROPAGE, these also get affected in the same way: - UFFDIO_CONTINUE - UFFDIO_POISON - UFFDIO_MOVE This patch should have fixed all of them. Link: https://lkml.kernel.org/r/20250424215729.194656-2-peterx@redhat.com Fixes: df2cc96e7701 ("userfaultfd: prevent non-cooperative events vs mcopy_atomic races") Fixes: f619147104c8 ("userfaultfd: add UFFDIO_CONTINUE ioctl") Fixes: fc71884a5f59 ("mm: userfaultfd: add new UFFDIO_POISON ioctl") Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by: Peter Xu Reported-by: Andrea Arcangeli Suggested-by: Andrea Arcangeli Reviewed-by: David Hildenbrand Cc: Mike Rapoport Cc: Axel Rasmussen Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6166c3cf405441f7147b322980144feb3cefc617 Author: Gavin Guo Date: Mon Apr 21 19:35:36 2025 +0800 mm/huge_memory: fix dereferencing invalid pmd migration entry commit be6e843fc51a584672dfd9c4a6a24c8cb81d5fb7 upstream. When migrating a THP, concurrent access to the PMD migration entry during a deferred split scan can lead to an invalid address access, as illustrated below. To prevent this invalid access, it is necessary to check the PMD migration entry and return early. In this context, there is no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the equality of the target folio. Since the PMD migration entry is locked, it cannot be served as the target. Mailing list discussion and explanation from Hugh Dickins: "An anon_vma lookup points to a location which may contain the folio of interest, but might instead contain another folio: and weeding out those other folios is precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of replacing the wrong folio" comment a few lines above it) is for." BUG: unable to handle page fault for address: ffffea60001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60 Call Trace: try_to_migrate_one+0x28c/0x3730 rmap_walk_anon+0x4f6/0x770 unmap_folio+0x196/0x1f0 split_huge_page_to_list_to_order+0x9f6/0x1560 deferred_split_scan+0xac5/0x12a0 shrinker_debugfs_scan_write+0x376/0x470 full_proxy_write+0x15c/0x220 vfs_write+0x2fc/0xcb0 ksys_write+0x146/0x250 do_syscall_64+0x6a/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e The bug is found by syzkaller on an internal kernel, then confirmed on upstream. Link: https://lkml.kernel.org/r/20250421113536.3682201-1-gavinguo@igalia.com Link: https://lore.kernel.org/all/20250414072737.1698513-1-gavinguo@igalia.com/ Link: https://lore.kernel.org/all/20250418085802.2973519-1-gavinguo@igalia.com/ Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path") Signed-off-by: Gavin Guo Acked-by: David Hildenbrand Acked-by: Hugh Dickins Acked-by: Zi Yan Reviewed-by: Gavin Shan Cc: Florent Revest Cc: Matthew Wilcox (Oracle) Cc: Miaohe Lin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2910019b04ebb200b03761f0d1eefe9c3599f5d5 Author: Kees Cook Date: Fri Apr 25 17:11:07 2025 -0700 mm: vmalloc: support more granular vrealloc() sizing commit a0309faf1cb0622cac7c820150b7abf2024acff5 upstream. Introduce struct vm_struct::requested_size so that the requested (re)allocation size is retained separately from the allocated area size. This means that KASAN will correctly poison the correct spans of requested bytes. This also means we can support growing the usable portion of an allocation that can already be supported by the existing area's existing allocation. Link: https://lkml.kernel.org/r/20250426001105.it.679-kees@kernel.org Fixes: 3ddc2fefe6f3 ("mm: vmalloc: implement vrealloc()") Signed-off-by: Kees Cook Reported-by: Erhard Furtner Closes: https://lore.kernel.org/all/20250408192503.6149a816@outsider.home/ Reviewed-by: Danilo Krummrich Cc: Michal Hocko Cc: "Uladzislau Rezki (Sony)" Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit efb597345953d06860bbdbf6aab38ea25ee4b438 Author: Petr Vaněk Date: Fri May 2 23:50:19 2025 +0200 mm: fix folio_pte_batch() on XEN PV commit 7b08b74f3d99f6b801250683c751d391128799ec upstream. On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a folio due to a corner case in pte_advance_pfn(). Specifically, when the PFN following the folio maps to an invalidated MFN, expected_pte = pte_advance_pfn(expected_pte, nr); produces a pte_none(). If the actual next PTE in memory is also pte_none(), the pte_same() succeeds, if (!pte_same(pte, expected_pte)) break; the loop is not broken, and batching continues into unrelated memory. For example, with a 4-page folio, the PTE layout might look like this: [ 53.465673] [ T2552] folio_pte_batch: printing PTE values at addr=0x7f1ac9dc5000 [ 53.465674] [ T2552] PTE[453] = 000000010085c125 [ 53.465679] [ T2552] PTE[454] = 000000010085d125 [ 53.465682] [ T2552] PTE[455] = 000000010085e125 [ 53.465684] [ T2552] PTE[456] = 000000010085f125 [ 53.465686] [ T2552] PTE[457] = 0000000000000000 <-- not present [ 53.465689] [ T2552] PTE[458] = 0000000101da7125 pte_advance_pfn(PTE[456]) returns a pte_none() due to invalid PFN->MFN mapping. The next actual PTE (PTE[457]) is also pte_none(), so the loop continues and includes PTE[457] in the batch, resulting in 5 batched entries for a 4-page folio. This triggers the following warning: [ 53.465751] [ T2552] page: refcount:85 mapcount:20 mapping:ffff88813ff4f6a8 index:0x110 pfn:0x10085c [ 53.465754] [ T2552] head: order:2 mapcount:80 entire_mapcount:0 nr_pages_mapped:4 pincount:0 [ 53.465756] [ T2552] memcg:ffff888003573000 [ 53.465758] [ T2552] aops:0xffffffff8226fd20 ino:82467c dentry name(?):"libc.so.6" [ 53.465761] [ T2552] flags: 0x2000000000416c(referenced|uptodate|lru|active|private|head|node=0|zone=2) [ 53.465764] [ T2552] raw: 002000000000416c ffffea0004021f08 ffffea0004021908 ffff88813ff4f6a8 [ 53.465767] [ T2552] raw: 0000000000000110 ffff888133d8bd40 0000005500000013 ffff888003573000 [ 53.465768] [ T2552] head: 002000000000416c ffffea0004021f08 ffffea0004021908 ffff88813ff4f6a8 [ 53.465770] [ T2552] head: 0000000000000110 ffff888133d8bd40 0000005500000013 ffff888003573000 [ 53.465772] [ T2552] head: 0020000000000202 ffffea0004021701 000000040000004f 00000000ffffffff [ 53.465774] [ T2552] head: 0000000300000003 8000000300000002 0000000000000013 0000000000000004 [ 53.465775] [ T2552] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) Original code works as expected everywhere, except on XEN PV, where pte_advance_pfn() can yield a pte_none() after balloon inflation due to MFNs invalidation. In XEN, pte_advance_pfn() ends up calling __pte()->xen_make_pte()->pte_pfn_to_mfn(), which returns pte_none() when mfn == INVALID_P2M_ENTRY. The pte_pfn_to_mfn() documents that nastiness: If there's no mfn for the pfn, then just create an empty non-present pte. Unfortunately this loses information about the original pfn, so pte_mfn_to_pfn is asymmetric. While such hacks should certainly be removed, we can do better in folio_pte_batch() and simply check ahead of time how many PTEs we can possibly batch in our folio. This way, we can not only fix the issue but cleanup the code: removing the pte_pfn() check inside the loop body and avoiding end_ptr comparison + arithmetic. Link: https://lkml.kernel.org/r/20250502215019.822-2-arkamar@atlas.cz Fixes: f8d937761d65 ("mm/memory: optimize fork() with PTE-mapped THP") Co-developed-by: David Hildenbrand Signed-off-by: David Hildenbrand Signed-off-by: Petr Vaněk Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d87392094f96e162fa5fa5a8640d70cc0952806f Author: Dave Hansen Date: Thu May 8 15:41:32 2025 -0700 x86/mm: Eliminate window where TLB flushes may be inadvertently skipped commit fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a upstream. tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: // Turn on IPIs for this CPU/mm combination, but only // if should_flush_tlb() agrees: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ After 'need_flush' is set to false, IPIs *MUST* // be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ Not until this point does should_flush_tlb() // become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written. Signed-off-by: Dave Hansen Acked-by: Rik van Riel Link: https://lore.kernel.org/oe-lkp/202411282207.6bd28eae-lkp@intel.com/ [1] Fixes: 6db2526c1d69 ("x86/mm/tlb: Only trim the mm_cpumask once a second") [2] Reported-by: Stephen Dolan Cc: stable@vger.kernel.org Acked-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e8b1d65f0a931b1f367363f607e64bb46fe4e83d Author: Gabriel Shahrouzi Date: Fri Apr 18 21:29:37 2025 -0400 staging: axis-fifo: Correct handling of tx_fifo_depth for size validation commit 2ca34b508774aaa590fc3698a54204706ecca4ba upstream. Remove erroneous subtraction of 4 from the total FIFO depth read from device tree. The stored depth is for checking against total capacity, not initial vacancy. This prevented writes near the FIFO's full size. The check performed just before data transfer, which uses live reads of the TDFV register to determine current vacancy, correctly handles the initial Depth - 4 hardware state and subsequent FIFO fullness. Fixes: 4a965c5f89de ("staging: add driver for Xilinx AXI-Stream FIFO v4.1 IP core") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Link: https://lore.kernel.org/r/20250419012937.674924-1-gshahrouzi@gmail.com Signed-off-by: Greg Kroah-Hartman commit 38a8982ca0b7c7bcfd6bfeba921cde21ca744025 Author: Gabriel Shahrouzi Date: Fri Apr 18 20:43:06 2025 -0400 staging: axis-fifo: Remove hardware resets for user errors commit c6e8d85fafa7193613db37da29c0e8d6e2515b13 upstream. The axis-fifo driver performs a full hardware reset (via reset_ip_core()) in several error paths within the read and write functions. This reset flushes both TX and RX FIFOs and resets the AXI-Stream links. Allow the user to handle the error without causing hardware disruption or data loss in other FIFO paths. Fixes: 4a965c5f89de ("staging: add driver for Xilinx AXI-Stream FIFO v4.1 IP core") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Link: https://lore.kernel.org/r/20250419004306.669605-1-gshahrouzi@gmail.com Signed-off-by: Greg Kroah-Hartman commit 06753f49336ab161ea0e249a0720125b81b7b31b Author: Dave Stevenson Date: Wed Apr 23 11:47:15 2025 +0100 staging: bcm2835-camera: Initialise dev in v4l2_dev commit 98698ca0e58734bc5c1c24e5bbc7429f981cd186 upstream. Commit 42a2f6664e18 ("staging: vc04_services: Move global g_state to vchiq_state") changed mmal_init to pass dev->v4l2_dev.dev to vchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we got a NULL pointer dereference. Set dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointer could be passed into v4l2_device_register to set it, however that also has other effects that would need additional changes. Fixes: 42a2f6664e18 ("staging: vc04_services: Move global g_state to vchiq_state") Cc: stable@vger.kernel.org Signed-off-by: Dave Stevenson Reviewed-by: Stefan Wahren Link: https://lore.kernel.org/r/20250423-staging-bcm2835-v4l2-fix-v2-1-3227f0ba4700@raspberrypi.com Signed-off-by: Greg Kroah-Hartman commit 215e42e2f12cd737a8fc2ff9450d4c423fbfbb2d Author: Gabriel Shahrouzi Date: Mon Apr 14 11:40:49 2025 -0400 staging: iio: adc: ad7816: Correct conditional logic for store mode commit 2e922956277187655ed9bedf7b5c28906e51708f upstream. The mode setting logic in ad7816_store_mode was reversed due to incorrect handling of the strcmp return value. strcmp returns 0 on match, so the `if (strcmp(buf, "full"))` block executed when the input was not "full". This resulted in "full" setting the mode to AD7816_PD (power-down) and other inputs setting it to AD7816_FULL. Fix this by checking it against 0 to correctly check for "full" and "power-down", mapping them to AD7816_FULL and AD7816_PD respectively. Fixes: 7924425db04a ("staging: iio: adc: new driver for AD7816 devices") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi Acked-by: Nuno Sá Link: https://lore.kernel.org/stable/20250414152920.467505-1-gshahrouzi%40gmail.com Link: https://patch.msgid.link/20250414154050.469482-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5bb112f1600844d7afd5f0f280b30a72206a9486 Author: Miguel Ojeda Date: Fri May 2 16:02:36 2025 +0200 rust: clean Rust 1.88.0's warning about `clippy::disallowed_macros` configuration commit c016722fd57551f8a6fcf472c9d2bcf2130ea0ec upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1], Clippy may start warning about paths that do not resolve in the `disallowed_macros` configuration: warning: `kernel::dbg` does not refer to an existing macro --> .clippy.toml:10:5 | 10 | { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" }, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a lint we requested at [2], due to the trouble debugging the lint due to false negatives (e.g. [3]), which we use to emulate `clippy::dbg_macro` [4]. See commit 8577c9dca799 ("rust: replace `clippy::dbg_macro` with `disallowed_macros`") for more details. Given the false negatives are not resolved yet, it is expected that Clippy complains about not finding this macro. Thus, until the false negatives are fixed (and, even then, probably we will need to wait for the MSRV to raise enough), use the escape hatch to allow an invalid path. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/14397 [1] Link: https://github.com/rust-lang/rust-clippy/issues/11432 [2] Link: https://github.com/rust-lang/rust-clippy/issues/11431 [3] Link: https://github.com/rust-lang/rust-clippy/issues/11303 [4] Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit a85d8aed0c0822cca8c7d5a719e84feebbbaa486 Author: Miguel Ojeda Date: Fri May 2 16:02:33 2025 +0200 objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0 commit 19f5ca461d5fc09bdf93a9f8e4bd78ed3a49dc71 upstream. Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report: rust/core.o: warning: objtool: _R..._4core9panicking9panic_fmt() falls through to next function _R..._4core9panicking18panic_nounwind_fmt() rust/core.o: warning: objtool: _R..._4core9panicking18panic_nounwind_fmt() falls through to next function _R..._4core9panicking5panic() The reason is that `rust_begin_unwind` is now mangled: _R..._7___rustc17rust_begin_unwind Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Alternatively, we could remove the fixed one in `noreturn.h` and relax this test to cover both, but it seems best to be strict as long as we can. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 376b73292a262124c8aed10026e9da23e92554b2 Author: Miguel Ojeda Date: Fri May 2 16:02:35 2025 +0200 rust: clean Rust 1.88.0's `unnecessary_transmutes` lint commit 7129ea6e242b00938532537da41ddf5fa3e21471 upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1][2], `rustc` may introduce a new lint that catches unnecessary transmutes, e.g.: error: unnecessary transmute --> rust/uapi/uapi_generated.rs:23242:18 | 23242 | unsafe { ::core::mem::transmute(self._bitfield_1.get(0usize, 1u8) as u8) } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: `(self._bitfield_1.get(0usize, 1u8) as u8 == 1)` | = note: `-D unnecessary-transmutes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unnecessary_transmutes)]` There are a lot of them (at least 300), but luckily they are all in `bindgen`-generated code. Thus clean all up by allowing it there. Since unknown lints trigger a lint itself in older compilers, do it conditionally so that we can keep the `unknown_lints` lint enabled. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/136083 [1] Link: https://github.com/rust-lang/rust/issues/136067 [2] Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250502140237.1659624-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 2943297acfea01c29a685d87232dfb6700cc72ff Author: Aditya Garg Date: Wed May 7 12:09:00 2025 -0700 Input: synaptics - enable InterTouch on TUXEDO InfinityBook Pro 14 v5 commit 2abc698ac77314e0de5b33a6d96a39c5159d88e4 upstream. Enable InterTouch mode on TUXEDO InfinityBook Pro 14 v5 by adding "SYN1221" to the list of SMBus-enabled variants. Add support for InterTouch on SYN1221 by adding it to the list of SMBus-enabled variants. Reported-by: Matthias Eilert Tested-by: Matthias Eilert Signed-off-by: Aditya Garg Link: https://lore.kernel.org/r/PN3PR01MB9597C033C4BC20EE2A0C4543B888A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a82f4f5563b6ec29ef93b7c80e8e28b446d52d14 Author: Dmitry Torokhov Date: Wed May 7 14:52:55 2025 -0700 Input: synaptics - enable SMBus for HP Elitebook 850 G1 commit f04f03d3e99bc8f89b6af5debf07ff67d961bc23 upstream. The kernel reports that the touchpad for this device can support SMBus mode. Reported-by: jt Link: https://lore.kernel.org/r/iys5dbv3ldddsgobfkxldazxyp54kay4bozzmagga6emy45jop@2ebvuxgaui4u Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bbb5081015ed0e225bd4814b5b545e1df36c638e Author: Aditya Garg Date: Wed May 7 12:12:15 2025 -0700 Input: synaptics - enable InterTouch on Dell Precision M3800 commit a609cb4cc07aa9ab8f50466622814356c06f2c17 upstream. Enable InterTouch mode on Dell Precision M3800 by adding "DLL060d" to the list of SMBus-enabled variants. Reported-by: Markus Rathgeb Signed-off-by: Aditya Garg Link: https://lore.kernel.org/r/PN3PR01MB959789DD6D574E16141E5DC4B888A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bc4556bba1c8eaf0665149a805d80b706bf1fda2 Author: Aditya Garg Date: Wed May 7 12:06:32 2025 -0700 Input: synaptics - enable InterTouch on Dynabook Portege X30L-G commit 47d768b32e644b56901bb4bbbdb1feb01ea86c85 upstream. Enable InterTouch mode on Dynabook Portege X30L-G by adding "TOS01f6" to the list of SMBus-enabled variants. Reported-by: Xuntao Chi Tested-by: Xuntao Chi Signed-off-by: Aditya Garg Link: https://lore.kernel.org/r/PN3PR01MB959786E4AC797160CDA93012B888A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9d9074af50e8fd35a45a9eaa960f78a12e7ff7f1 Author: Manuel Fombuena Date: Wed May 7 12:05:26 2025 -0700 Input: synaptics - enable InterTouch on Dynabook Portege X30-D commit 6d7ea0881000966607772451b789b5fb5766f11d upstream. [ 5.989588] psmouse serio1: synaptics: Your touchpad (PNP: TOS0213 PNP0f03) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org. [ 6.039923] psmouse serio1: synaptics: Touchpad model: 1, fw: 9.32, id: 0x1e2a1, caps: 0xf00223/0x840300/0x12e800/0x52d884, board id: 3322, fw id: 2658004 The board is labelled TM3322. Present on the Toshiba / Dynabook Portege X30-D and possibly others. Confirmed working well with psmouse.synaptics_intertouch=1 and local build. Signed-off-by: Manuel Fombuena Signed-off-by: Aditya Garg Link: https://lore.kernel.org/r/PN3PR01MB9597711E7933A08389FEC31DB888A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 38bb0170d6ad94644ed1e0a4ace285ff073a7973 Author: Vicki Pfau Date: Fri Mar 28 16:43:36 2025 -0700 Input: xpad - fix two controller table values commit d05a424bea9aa3435009d5c462055008cc1545d8 upstream. Two controllers -- Mad Catz JOYTECH NEO SE Advanced and PDP Mirror's Edge Official -- were missing the value of the mapping field, and thus wouldn't detect properly. Signed-off-by: Vicki Pfau Link: https://lore.kernel.org/r/20250328234345.989761-1-vi@endrift.com Fixes: 540602a43ae5 ("Input: xpad - add a few new VID/PID combinations") Fixes: 3492321e2e60 ("Input: xpad - add multiple supported devices") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bf239d383538d7b3638e9a4c9cfd409a63716806 Author: Lode Willems Date: Tue Apr 22 13:24:27 2025 +0200 Input: xpad - add support for 8BitDo Ultimate 2 Wireless Controller commit 22cd66a5db56a07d9e621367cb4d16ff0f6baf56 upstream. This patch adds support for the 8BitDo Ultimate 2 Wireless Controller. Tested using the wireless dongle and plugged in. Signed-off-by: Lode Willems Link: https://lore.kernel.org/r/20250422112457.6728-1-me@lodewillems.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 302a0cd0bbc450998429a3f4267970a4b93251a8 Author: Vicki Pfau Date: Sat May 10 22:59:25 2025 -0700 Input: xpad - fix Share button on Xbox One controllers commit 4ef46367073b107ec22f46fe5f12176e87c238e8 upstream. The Share button, if present, is always one of two offsets from the end of the file, depending on the presence of a specific interface. As we lack parsing for the identify packet we can't automatically determine the presence of that interface, but we can hardcode which of these offsets is correct for a given controller. More controllers are probably fixable by adding the MAP_SHARE_BUTTON in the future, but for now I only added the ones that I have the ability to test directly. Signed-off-by: Vicki Pfau Link: https://lore.kernel.org/r/20250328234345.989761-2-vi@endrift.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 619c05fb176c272ac6cecf723446b39723ee6d97 Author: Gary Bisson Date: Tue Apr 29 09:16:29 2025 -0700 Input: mtk-pmic-keys - fix possible null pointer dereference commit 11cdb506d0fbf5ac05bf55f5afcb3a215c316490 upstream. In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway. Fixes: b581acb49aec ("Input: mtk-pmic-keys - transfer per-key bit in mtk_pmic_keys_regs") Signed-off-by: Gary Bisson Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f36230dacde99a0fa5f1b4a7032fa28f4703adbc Author: Mikael Gonella-Bolduc Date: Wed Apr 23 09:52:43 2025 -0400 Input: cyttsp5 - fix power control issue on wakeup commit 7675b5efd81fe6d524e29d5a541f43201e98afa8 upstream. The power control function ignores the "on" argument when setting the report ID, and thus is always sending HID_POWER_SLEEP. This causes a problem when trying to wakeup. Fix by sending the state variable, which contains the proper HID_POWER_ON or HID_POWER_SLEEP based on the "on" argument. Fixes: 3c98b8dbdced ("Input: cyttsp5 - implement proper sleep and wakeup procedures") Cc: stable@vger.kernel.org Signed-off-by: Mikael Gonella-Bolduc Signed-off-by: Hugo Villeneuve Reviewed-by: Alistair Francis Link: https://lore.kernel.org/r/20250423135243.1261460-1-hugo@hugovil.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ee25256789c31ab4f379af89fcf7ddb2cc72f0fd Author: Hugo Villeneuve Date: Thu Apr 10 14:46:32 2025 -0400 Input: cyttsp5 - ensure minimum reset pulse width commit c6cb8bf79466ae66bd0d07338c7c505ce758e9d7 upstream. The current reset pulse width is measured to be 5us on a Renesas RZ/G2L SOM. The manufacturer's minimum reset pulse width is specified as 10us. Extend reset pulse width to make sure it is long enough on all platforms. Also reword confusing comments about reset pin assertion. Fixes: 5b0c03e24a06 ("Input: Add driver for Cypress Generation 5 touchscreen") Cc: stable@vger.kernel.org Acked-by: Alistair Francis Signed-off-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20250410184633.1164837-1-hugo@hugovil.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit de02eb727f1a296c9459512586d069397db3f34c Author: Jakub Kicinski Date: Tue May 6 17:32:21 2025 -0700 virtio-net: fix total qstat values [ Upstream commit 001160ec8c59115efc39e197d40829bdafd4d7f5 ] NIPA tests report that the interface statistics reported via qstat are lower than those reported via ip link. Looks like this is because some tests flip the queue count up and down, and we end up with some of the traffic accounted on disabled queues. Add up counters from disabled queues. Fixes: d888f04c09bb ("virtio-net: support queue stat") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20250507003221.823267-3-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bb8f86f40e04fe32b36679ac3b5deebcca2b99b9 Author: Jakub Kicinski Date: Tue May 6 17:32:20 2025 -0700 net: export a helper for adding up queue stats [ Upstream commit 23fa6a23d97182d36ca3c71e43c804fa91e46a03 ] Older drivers and drivers with lower queue counts often have a static array of queues, rather than allocating structs for each queue on demand. Add a helper for adding up qstats from a queue range. Expectation is that driver will pass a queue range [netdev->real_num_*x_queues, MAX). It was tempting to always use num_*x_queues as the end, but virtio seems to clamp its queue count after allocating the netdev. And this way we can trivaly reuse the helper for [0, real_..). Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20250507003221.823267-2-kuba@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 001160ec8c59 ("virtio-net: fix total qstat values") Signed-off-by: Sasha Levin commit 7eea40818e8f145b9f890b13610c71f4d62ecc9a Author: Alexander Duyck Date: Tue May 6 09:00:25 2025 -0700 fbnic: Do not allow mailbox to toggle to ready outside fbnic_mbx_poll_tx_ready [ Upstream commit ce2fa1dba204c761582674cf2eb9cbe0b949b5c7 ] We had originally thought to have the mailbox go to ready in the background while we were doing other things. One issue with this though is that we can't disable it by clearing the ready state without also blocking interrupts or calls to mbx_poll as it will just pop back to life during an interrupt. In order to prevent that from happening we can pull the code for toggling to ready out of the interrupt path and instead place it in the fbnic_mbx_poll_tx_ready path so that it becomes the only spot where the Rx/Tx can toggle to the ready state. By doing this we can prevent races where we disable the DMA and/or free buffers only to have an interrupt fire and undo what we have done. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck Reviewed-by: Jacob Keller Link: https://patch.msgid.link/174654722518.499179.11612865740376848478.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 650e283b4cd3c469760dc125611d95e9e442dd21 Author: Alexander Duyck Date: Tue May 6 09:00:18 2025 -0700 fbnic: Pull fbnic_fw_xmit_cap_msg use out of interrupt context [ Upstream commit 1b34d1c1dc8384884febd83140c9afbc7c4b9eb8 ] This change pulls the call to fbnic_fw_xmit_cap_msg out of fbnic_mbx_init_desc_ring and instead places it in the polling function for getting the Tx ready. Doing that we can avoid the potential issue with an interrupt coming in later from the firmware that causes it to get fired in interrupt context. Fixes: 20d2e88cc746 ("eth: fbnic: Add initial messaging to notify FW of our presence") Signed-off-by: Alexander Duyck Reviewed-by: Jacob Keller Link: https://patch.msgid.link/174654721876.499179.9839651602256668493.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9d9010879dc93bdf2aee4f028c8bc7405134c0cd Author: Alexander Duyck Date: Tue May 6 09:00:12 2025 -0700 fbnic: Improve responsiveness of fbnic_mbx_poll_tx_ready [ Upstream commit ab064f6005973d456f95ae99cd9ea0d8ab676cce ] There were a couple different issues found in fbnic_mbx_poll_tx_ready. Among them were the fact that we were sleeping much longer than we actually needed to as the actual FW could respond in under 20ms. The other issue was that we would just keep polling the mailbox even if the device itself had gone away. To address the responsiveness issues we can decrease the sleeps to 20ms and use a jiffies based timeout value rather than just counting the number of times we slept and then polled. To address the hardware going away we can move the check for the firmware BAR being present from where it was and place it inside the loop after the mailbox descriptor ring is initialized and before we sleep so that we just abort and return an error if the device went away during initialization. With these two changes we see a significant improvement in boot times for the driver. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck Reviewed-by: Jacob Keller Link: https://patch.msgid.link/174654721224.499179.2698616208976624755.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 612a05c9f20c08faa9991c3eb7e99ff3a0698dd2 Author: Alexander Duyck Date: Tue May 6 08:59:59 2025 -0700 fbnic: Actually flush_tx instead of stalling out [ Upstream commit 0f9a959a0addd9bbc47e5d16c36b3a7f97981915 ] The fbnic_mbx_flush_tx function had a number of issues. First, we were waiting 200ms for the firmware to process the packets. We can drop this to 20ms and in almost all cases this should be more than enough time. So by changing this we can significantly reduce shutdown time. Second, we were not making sure that the Tx path was actually shut off. As such we could still have packets added while we were flushing the mailbox. To prevent that we can now clear the ready flag for the Tx side and it should stay down since the interrupt is disabled. Third, we kept re-reading the tail due to the second issue. The tail should not move after we have started the flush so we can just read it once while we are holding the mailbox Tx lock. By doing that we are guaranteed that the value should be consistent. Fourth, we were keeping a count of descriptors cleaned due to the second and third issues called out. That count is not a valid reason to be exiting the cleanup, and with the tail only being read once we shouldn't see any cases where the tail moves after the disable so the tracking of count can be dropped. Fifth, we were using attempts * sleep time to determine how long we would wait in our polling loop to flush out the Tx. This can be very imprecise. In order to tighten up the timing we are shifting over to using a jiffies value of jiffies + 10 * HZ + 1 to determine the jiffies value we should stop polling at as this should be accurate within once sleep cycle for the total amount of time spent polling. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Link: https://patch.msgid.link/174654719929.499179.16406653096197423749.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fea860a2a6136658708fb530a82d59d29f708b74 Author: Alexander Duyck Date: Tue May 6 08:59:46 2025 -0700 fbnic: Gate AXI read/write enabling on FW mailbox [ Upstream commit 3b12f00ddd08e888273b2ac0488d396d90a836fc ] In order to prevent the device from throwing spurious writes and/or reads at us we need to gate the AXI fabric interface to the PCIe until such time as we know the FW is in a known good state. To accomplish this we use the mailbox as a mechanism for us to recognize that the FW has acknowledged our presence and is no longer sending any stale message data to us. We start in fbnic_mbx_init by calling fbnic_mbx_reset_desc_ring function, disabling the DMA in both directions, and then invalidating all the descriptors in each ring. We then poll the mailbox in fbnic_mbx_poll_tx_ready and when the interrupt is set by the FW we pick it up and mark the mailboxes as ready, while also enabling the DMA. Once we have completed all the transactions and need to shut down we call into fbnic_mbx_clean which will in turn call fbnic_mbx_reset_desc_ring for each ring and shut down the DMA and once again invalidate the descriptors. Fixes: 3646153161f1 ("eth: fbnic: Add register init to set PCIe/Ethernet device config") Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Link: https://patch.msgid.link/174654718623.499179.7445197308109347982.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cd25fc4c562eac2fcdba969560b672b45e5d3161 Author: Alexander Duyck Date: Tue May 6 08:59:39 2025 -0700 fbnic: Fix initialization of mailbox descriptor rings [ Upstream commit f34343cc11afc7bb1f881c3492bee3484016bf71 ] Address to issues with the FW mailbox descriptor initialization. We need to reverse the order of accesses when we invalidate an entry versus writing an entry. When writing an entry we write upper and then lower as the lower 32b contain the valid bit that makes the entire address valid. However for invalidation we should write it in the reverse order so that the upper is marked invalid before we update it. Without this change we may see FW attempt to access pages with the upper 32b of the address set to 0 which will likely result in DMAR faults due to write access failures on mailbox shutdown. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Link: https://patch.msgid.link/174654717972.499179.8083789731819297034.stgit@ahduyck-xeon-server.home.arpa Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ce97489864c9a78b4b8b513e575b26e9ec382a5a Author: Jonas Gorski Date: Tue Apr 29 22:17:10 2025 +0200 net: dsa: b53: do not set learning and unicast/multicast on up [ Upstream commit 2e7179c628d3cb9aee75e412473813b099e11ed4 ] When a port gets set up, b53 disables learning and enables the port for flooding. This can undo any bridge configuration on the port. E.g. the following flow would disable learning on a port: $ ip link add br0 type bridge $ ip link set sw1p1 master br0 <- enables learning for sw1p1 $ ip link set br0 up $ ip link set sw1p1 up <- disables learning again Fix this by populating dsa_switch_ops::port_setup(), and set up initial config there. Fixes: f9b3827ee66c ("net: dsa: b53: Support setting learning on port") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-12-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e5b40f4a2b3e16819a7f9d129d077eb7a4d2a20d Author: Jonas Gorski Date: Tue Apr 29 22:17:09 2025 +0200 net: dsa: b53: fix learning on VLAN unaware bridges [ Upstream commit 9f34ad89bcf0e6df6f8b01f1bdab211493fc66d1 ] When VLAN filtering is off, we configure the switch to forward, but not learn on VLAN table misses. This effectively disables learning while not filtering. Fix this by switching to forward and learn. Setting the learning disable register will still control whether learning actually happens. Fixes: dad8d7c6452b ("net: dsa: b53: Properly account for VLAN filtering") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-11-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce1a289bf2abed50311d9668cdbf0c8f3fab8345 Author: Jonas Gorski Date: Tue Apr 29 22:17:08 2025 +0200 net: dsa: b53: fix toggling vlan_filtering [ Upstream commit 2dc2bd57111582895e10f54ea380329c89873f1c ] To allow runtime switching between vlan aware and vlan non-aware mode, we need to properly keep track of any bridge VLAN configuration. Likewise, we need to know when we actually switch between both modes, to not have to rewrite the full VLAN table every time we update the VLANs. So keep track of the current vlan_filtering mode, and on changes, apply the appropriate VLAN configuration. Fixes: 0ee2af4ebbe3 ("net: dsa: set configure_vlan_while_not_filtering to true by default") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-10-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2407c98a1b4c94d86294f84fdb30901bc7497978 Author: Jonas Gorski Date: Tue Apr 29 22:17:07 2025 +0200 net: dsa: b53: do not program vlans when vlan filtering is off [ Upstream commit f089652b6b16452535dcc5cbaa6e2bb05acd3f93 ] Documentation/networking/switchdev.rst says: - with VLAN filtering turned off: the bridge is strictly VLAN unaware and its data path will process all Ethernet frames as if they are VLAN-untagged. The bridge VLAN database can still be modified, but the modifications should have no effect while VLAN filtering is turned off. This breaks if we immediately apply the VLAN configuration, so skip writing it when vlan_filtering is off. Fixes: 0ee2af4ebbe3 ("net: dsa: set configure_vlan_while_not_filtering to true by default") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-9-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7dac025829118c21271dbd72700dbebdcefd0672 Author: Jonas Gorski Date: Tue Apr 29 22:17:06 2025 +0200 net: dsa: b53: do not allow to configure VLAN 0 [ Upstream commit 45e9d59d39503bb3e6ab4d258caea4ba6496e2dc ] Since we cannot set forwarding destinations per VLAN, we should not have a VLAN 0 configured, as it would allow untagged traffic to work across ports on VLAN aware bridges regardless if a PVID untagged VLAN exists. So remove the VLAN 0 on join, an re-add it on leave. But only do so if we have a VLAN aware bridge, as without it, untagged traffic would become tagged with VID 0 on a VLAN unaware bridge. Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-8-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11c427a8699e4b21e6641336502d0d58979db778 Author: Jonas Gorski Date: Tue Apr 29 22:17:05 2025 +0200 net: dsa: b53: always rejoin default untagged VLAN on bridge leave [ Upstream commit 13b152ae40495966501697693f048f47430c50fd ] While JOIN_ALL_VLAN allows to join all VLANs, we still need to keep the default VLAN enabled so that untagged traffic stays untagged. So rejoin the default VLAN even for switches with JOIN_ALL_VLAN support. Fixes: 48aea33a77ab ("net: dsa: b53: Add JOIN_ALL_VLAN support") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-7-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 90b65bc357ca2d7ba11edc08c23cf09472fa35b5 Author: Jonas Gorski Date: Tue Apr 29 22:17:04 2025 +0200 net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave [ Upstream commit a1c1901c5cc881425cc45992ab6c5418174e9e5a ] The untagged default VLAN is added to the default vlan, which may be one, but we modify the VLAN 0 entry on bridge leave. Fix this to use the correct VLAN entry for the default pvid. Fixes: fea83353177a ("net: dsa: b53: Fix default VLAN ID") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-6-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42ab1f2b6f4575b0b0fa77ff11369cf351e6038c Author: Jonas Gorski Date: Tue Apr 29 22:17:03 2025 +0200 net: dsa: b53: fix flushing old pvid VLAN on pvid change [ Upstream commit 083c6b28c0cbcd83b6af1a10f2c82937129b3438 ] Presumably the intention here was to flush the VLAN of the old pvid, not the added VLAN again, which we already flushed before. Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-5-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4ed7e603139fb848b9bf06ae303fdc88c271ea71 Author: Jonas Gorski Date: Tue Apr 29 22:17:02 2025 +0200 net: dsa: b53: fix clearing PVID of a port [ Upstream commit f480851981043d9bb6447ca9883ade9247b9a0ad ] Currently the PVID of ports are only set when adding/updating VLANs with PVID set or removing VLANs, but not when clearing the PVID flag of a VLAN. E.g. the following flow $ ip link add br0 type bridge vlan_filtering 1 $ ip link set sw1p1 master bridge $ bridge vlan add dev sw1p1 vid 10 pvid untagged $ bridge vlan add dev sw1p1 vid 10 untagged Would keep the PVID set as 10, despite the flag being cleared. Fix this by checking if we need to unset the PVID on vlan updates. Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-4-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46de8f2aa389a10c86796aea2383d5c8411eb790 Author: Jonas Gorski Date: Tue Apr 29 22:17:01 2025 +0200 net: dsa: b53: keep CPU port always tagged again [ Upstream commit 425f11d4cc9bd9e97e6825d9abb2c51a068ca7b5 ] The Broadcom management header does not carry the original VLAN tag state information, just the ingress port, so for untagged frames we do not know from which VLAN they originated. Therefore keep the CPU port always tagged except for VLAN 0. Fixes the following setup: $ ip link add br0 type bridge vlan_filtering 1 $ ip link set sw1p1 master br0 $ bridge vlan add dev br0 pvid untagged self $ ip link add sw1p2.10 link sw1p2 type vlan id 10 Where VID 10 would stay untagged on the CPU port. Fixes: 2c32a3d3c233 ("net: dsa: b53: Do not force CPU to be always tagged") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11dbd4e0a89a8f229eb952a4ac8b50ce8c182504 Author: Jonas Gorski Date: Tue Apr 29 22:17:00 2025 +0200 net: dsa: b53: allow leaky reserved multicast [ Upstream commit 5f93185a757ff38b36f849c659aeef368db15a68 ] Allow reserved multicast to ignore VLAN membership so STP and other management protocols work without a PVID VLAN configured when using a vlan aware bridge. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Jonas Gorski Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250429201710.330937-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b37e54259cab4f78b53953d6f6268b85f07bef3e Author: Paul Chaignon Date: Mon May 5 21:58:04 2025 +0200 bpf: Scrub packet on bpf_redirect_peer [ Upstream commit c4327229948879814229b46aa26a750718888503 ] When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed. Fixes: 9aa1206e8f482 ("bpf: Add redirect_peer helper") Signed-off-by: Paul Chaignon Acked-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://patch.msgid.link/1728ead5e0fe45e7a6542c36bd4e3ca07a73b7d6.1746460653.git.paul.chaignon@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2ab67672b2288521a6146034a971f9a82ffc5c5 Author: Jozsef Kadlecsik Date: Wed May 7 17:01:59 2025 +0200 netfilter: ipset: fix region locking in hash types [ Upstream commit 8478a729c0462273188263136880480729e9efca ] Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts. Fixes: f66ee0410b1c ("netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports") Reported-by: Kota Toda Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0160ac84fb03a0bd8dce8a42cb25bfaeedd110f4 Author: Julian Anastasov Date: Sat May 3 01:01:18 2025 +0300 ipvs: fix uninit-value for saddr in do_output_route4 [ Upstream commit e34090d7214e0516eb8722aee295cb2507317c07 ] syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Reported-by: syzbot+04b9a82855c8aed20860@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68138dfa.050a0220.14dd7d.0017.GAE@google.com/ Fixes: 4754957f04f5 ("ipvs: do not use random local source address for tunnels") Signed-off-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 64385c0d02f7dae10096fca5e08ac0b207df8d5a Author: Gao Xiang Date: Tue May 6 18:18:50 2025 +0800 erofs: ensure the extra temporary copy is valid for shortened bvecs [ Upstream commit 35076d2223c731f7be75af61e67f90807384d030 ] When compressed data deduplication is enabled, multiple logical extents may reference the same compressed physical cluster. The previous commit 94c43de73521 ("erofs: fix wrong primary bvec selection on deduplicated extents") already avoids using shortened bvecs. However, in such cases, the extra temporary buffers also need to be preserved for later use in z_erofs_fill_other_copies() to to prevent data corruption. IOWs, extra temporary buffers have to be retained not only due to varying start relative offsets (`pageofs_out`, as indicated by `pcl->multibases`) but also because of shortened bvecs. android.hardware.graphics.composer@2.1.so : 270696 bytes 0: 0.. 204185 | 204185 : 628019200.. 628084736 | 65536 -> 1: 204185.. 225536 | 21351 : 544063488.. 544129024 | 65536 2: 225536.. 270696 | 45160 : 0.. 0 | 0 com.android.vndk.v28.apex : 93814897 bytes ... 364: 53869896..54095257 | 225361 : 543997952.. 544063488 | 65536 -> 365: 54095257..54309344 | 214087 : 544063488.. 544129024 | 65536 366: 54309344..54514557 | 205213 : 544129024.. 544194560 | 65536 ... Both 204185 and 54095257 have the same start relative offset of 3481, but the logical page 55 of `android.hardware.graphics.composer@2.1.so` ranges from 225280 to 229632, forming a shortened bvec [225280, 225536) that cannot be used for decompressing the range from 54095257 to 54309344 of `com.android.vndk.v28.apex`. Since `pcl->multibases` is already meaningless, just mark `be->keepxcpy` on demand for simplicity. Again, this issue can only lead to data corruption if `-Ededupe` is on. Fixes: 94c43de73521 ("erofs: fix wrong primary bvec selection on deduplicated extents") Reviewed-by: Hongbo Li Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20250506101850.191506-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit 574686c80754ebd144c0a3f6531010e6554a646b Author: Przemek Kitszel Date: Mon May 5 09:19:38 2025 -0700 ice: use DSN instead of PCI BDF for ice_adapter index [ Upstream commit 0093cb194a7511d1e68865fa35b763c72e44c2f0 ] Use Device Serial Number instead of PCI bus/device/function for the index of struct ice_adapter. Functions on the same physical device should point to the very same ice_adapter instance, but with two PFs, when at least one of them is PCI-e passed-through to a VM, it is no longer the case - PFs will get seemingly random PCI BDF values, and thus indices, what finally leds to each of them being on their own instance of ice_adapter. That causes them to don't attempt any synchronization of the PTP HW clock usage, or any other future resources. DSN works nicely in place of the index, as it is "immutable" in terms of virtualization. Fixes: 0e2bddf9e5f9 ("ice: add ice_adapter for shared data across PFs on the same NIC") Suggested-by: Jacob Keller Suggested-by: Jakub Kicinski Suggested-by: Jiri Pirko Reviewed-by: Aleksandr Loktionov Signed-off-by: Przemek Kitszel Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20250505161939.2083581-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 62946989e66023a8eed84f7d3a36021bb9af8c40 Author: Sergey Temerkhanov Date: Wed Aug 21 15:09:55 2024 +0200 ice: Initial support for E825C hardware in ice_adapter [ Upstream commit fdb7f54700b1c88e734323a62fea986d9ce5a9c6 ] Address E825C devices by PCI ID since dual IP core configurations need 1 ice_adapter for both devices. Signed-off-by: Sergey Temerkhanov Reviewed-by: Simon Horman Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: 0093cb194a75 ("ice: use DSN instead of PCI BDF for ice_adapter index") Signed-off-by: Sasha Levin commit 4555c4a13a930ea7775aed9fe4f5444642176cf9 Author: Michael-CY Lee Date: Mon May 5 16:19:46 2025 +0800 wifi: mac80211: fix the type of status_code for negotiated TID to Link Mapping [ Upstream commit e12a42f64fc3d74872b349eedd47f90c6676b78a ] The status code should be type of __le16. Fixes: 83e897a961b8 ("wifi: ieee80211: add definitions for negotiated TID to Link map") Fixes: 8f500fbc6c65 ("wifi: mac80211: process and save negotiated TID to Link mapping request") Signed-off-by: Michael-CY Lee Link: https://patch.msgid.link/20250505081946.3927214-1-michael-cy.lee@mediatek.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c33927f3858c555e7240e076f33a43143c2104a8 Author: Oliver Hartkopp Date: Tue Apr 29 09:05:55 2025 +0200 can: gw: fix RCU/BH usage in cgw_create_job() [ Upstream commit 511e64e13d8cc72853275832e3f372607466c18c ] As reported by Sebastian Andrzej Siewior the use of local_bh_disable() is only feasible in uni processor systems to update the modification rules. The usual use-case to update the modification rules is to update the data of the modifications but not the modification types (AND/OR/XOR/SET) or the checksum functions itself. To omit additional memory allocations to maintain fast modification switching times, the modification description space is doubled at gw-job creation time so that only the reference to the active modification description is changed under rcu protection. Rename cgw_job::mod to cf_mod and make it a RCU pointer. Allocate in cgw_create_job() and free it together with cgw_job in cgw_job_free_rcu(). Update all users to dereference cgw_job::cf_mod with a RCU accessor and if possible once. [bigeasy: Replace mod1/mod2 from the Oliver's original patch with dynamic allocation, use RCU annotation and accessor] Reported-by: Sebastian Andrzej Siewior Closes: https://lore.kernel.org/linux-can/20231031112349.y0aLoBrz@linutronix.de/ Fixes: dd895d7f21b2 ("can: cangw: introduce optional uid to reference created routing jobs") Tested-by: Oliver Hartkopp Signed-off-by: Oliver Hartkopp Signed-off-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20250429070555.cs-7b_eZ@linutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 8f24cc6a72eb5ac22f82a3e8dbc837f70d00f7e0 Author: Kelsey Maes Date: Wed Apr 30 09:15:01 2025 -0700 can: mcp251xfd: fix TDC setting for low data bit rates [ Upstream commit 5e1663810e11c64956aa7e280cf74b2f3284d816 ] The TDC is currently hardcoded enabled. This means that even for lower CAN-FD data bitrates (with a DBRP (data bitrate prescaler) > 2) a TDC is configured. This leads to a bus-off condition. ISO 11898-1 section 11.3.3 says "Transmitter delay compensation" (TDC) is only applicable if DBRP is 1 or 2. To fix the problem, switch the driver to use the TDC calculation provided by the CAN driver framework (which respects ISO 11898-1 section 11.3.3). This has the positive side effect that userspace can control TDC as needed. Demonstration of the feature in action: | $ ip link set can0 up type can bitrate 125000 dbitrate 500000 fd on | $ ip -details link show can0 | 3: can0: mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 | link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 | can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 | bitrate 125000 sample-point 0.875 | tq 50 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 10 brp 2 | mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1 | dbitrate 500000 dsample-point 0.875 | dtq 125 dprop-seg 6 dphase-seg1 7 dphase-seg2 2 dsjw 1 dbrp 5 | mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1 | tdcv 0..63 tdco 0..63 | clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0 | $ ip link set can0 up type can bitrate 1000000 dbitrate 4000000 fd on | $ ip -details link show can0 | 3: can0: mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 | link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 | can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 | bitrate 1000000 sample-point 0.750 | tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 5 brp 1 | mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1 | dbitrate 4000000 dsample-point 0.700 | dtq 25 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1 dbrp 1 | tdco 7 | mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1 | tdcv 0..63 tdco 0..63 | clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0 There has been some confusion about the MCP2518FD using a relative or absolute TDCO due to the datasheet specifying a range of [-64,63]. I have a custom board with a 40 MHz clock and an estimated loop delay of 100 to 216 ns. During testing at a data bit rate of 4 Mbit/s I found that using can_get_relative_tdco() resulted in bus-off errors. The final TDCO value was 1 which corresponds to a 10% SSP in an absolute configuration. This behavior is expected if the TDCO value is really absolute and not relative. Using priv->can.tdc.tdco instead results in a final TDCO of 8, setting the SSP at exactly 80%. This configuration works. The automatic, manual, and off TDC modes were tested at speeds up to, and including, 8 Mbit/s on real hardware and behave as expected. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reported-by: Kelsey Maes Closes: https://lore.kernel.org/all/C2121586-C87F-4B23-A933-845362C29CA1@vpprocess.com Reviewed-by: Vincent Mailhol Signed-off-by: Kelsey Maes Link: https://patch.msgid.link/20250430161501.79370-1-kelsey@vpprocess.com [mkl: add comment] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 2ecce25ea296f328d79070ee36229a15aeeb7aca Author: Antonios Salios Date: Fri Apr 25 13:17:45 2025 +0200 can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe [ Upstream commit dcaeeb8ae84c5506ebc574732838264f3887738c ] The spin lock tx_handling_spinlock in struct m_can_classdev is not being initialized. This leads the following spinlock bad magic complaint from the kernel, eg. when trying to send CAN frames with cansend from can-utils: | BUG: spinlock bad magic on CPU#0, cansend/95 | lock: 0xff60000002ec1010, .magic: 00000000, .owner: /-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Hardware name: MachineWare SIM-V (DT) | Call Trace: | [] dump_backtrace+0x1c/0x24 | [] show_stack+0x28/0x34 | [] dump_stack_lvl+0x4a/0x68 | [] dump_stack+0x14/0x1c | [] spin_dump+0x62/0x6e | [] do_raw_spin_lock+0xd0/0x142 | [] _raw_spin_lock_irqsave+0x20/0x2c | [] m_can_start_xmit+0x90/0x34a | [] dev_hard_start_xmit+0xa6/0xee | [] sch_direct_xmit+0x114/0x292 | [] __dev_queue_xmit+0x3b0/0xaa8 | [] can_send+0xc6/0x242 | [] raw_sendmsg+0x1a8/0x36c | [] sock_write_iter+0x9a/0xee | [] vfs_write+0x184/0x3a6 | [] ksys_write+0xa0/0xc0 | [] __riscv_sys_write+0x14/0x1c | [] do_trap_ecall_u+0x168/0x212 | [] handle_exception+0x146/0x152 Initializing the spin lock in m_can_class_allocate_dev solves that problem. Fixes: 1fa80e23c150 ("can: m_can: Introduce a tx_fifo_in_flight counter") Signed-off-by: Antonios Salios Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250425111744.37604-2-antonios@mwa.re Reviewed-by: Markus Schneider-Pargmann Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 79a6945e3de54339888fd3febcf4aef63dc735b8 Author: Frank Wunderlich Date: Mon May 5 02:07:58 2025 +0100 net: ethernet: mtk_eth_soc: do not reset PSE when setting FE [ Upstream commit e8716b5b0dff1b3d523b4a83fd5e94d57b887c5c ] Remove redundant PSE reset. When setting FE register there is no need to reset PSE, doing so may cause FE to work abnormal. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/3a5223473e086a4b54a2b9a44df7d9ddcc2bc75a Fixes: dee4dd10c79aa ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs") Signed-off-by: Frank Wunderlich Link: https://patch.msgid.link/18f0ac7d83f82defa3342c11ef0d1362f6b81e88.1746406763.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit aac9d5fa537b0c19f6d3af3c8a124028510bb647 Author: Daniel Golle Date: Mon May 5 02:07:32 2025 +0100 net: ethernet: mtk_eth_soc: reset all TX queues on DMA free [ Upstream commit 4db6c75124d871fbabf8243f947d34cc7e0697fc ] The purpose of resetting the TX queue is to reset the byte and packet count as well as to clear the software flow control XOFF bit. MediaTek developers pointed out that netdev_reset_queue would only resets queue 0 of the network device. Queues that are not reset may cause unexpected issues. Packets may stop being sent after reset and "transmit timeout" log may be displayed. Import fix from MediaTek's SDK to resolve this issue. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/319c0d9905579a46dc448579f892f364f1f84818 Fixes: f63959c7eec31 ("net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/c9ff9adceac4f152239a0f65c397f13547639175.1746406763.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 35be4c0cdf46a8ecf16733ec78c920213c7442b1 Author: Guillaume Nault Date: Sat May 3 00:57:52 2025 +0200 gre: Fix again IPv6 link-local address generation. [ Upstream commit 3e6a0243ff002ddbd7ee18a8974ae61d2e6ed00d ] Use addrconf_addr_gen() to generate IPv6 link-local addresses on GRE devices in most cases and fall back to using add_v4_addrs() only in case the GRE configuration is incompatible with addrconf_addr_gen(). GRE used to use addrconf_addr_gen() until commit e5dd729460ca ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") restricted this use to gretap and ip6gretap devices, and created add_v4_addrs() (borrowed from SIT) for non-Ethernet GRE ones. The original problem came when commit 9af28511be10 ("addrconf: refuse isatap eui64 for INADDR_ANY") made __ipv6_isatap_ifid() fail when its addr parameter was 0. The commit says that this would create an invalid address, however, I couldn't find any RFC saying that the generated interface identifier would be wrong. Anyway, since gre over IPv4 devices pass their local tunnel address to __ipv6_isatap_ifid(), that commit broke their IPv6 link-local address generation when the local address was unspecified. Then commit e5dd729460ca ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") tried to fix that case by defining add_v4_addrs() and calling it to generate the IPv6 link-local address instead of using addrconf_addr_gen() (apart for gretap and ip6gretap devices, which would still use the regular addrconf_addr_gen(), since they have a MAC address). That broke several use cases because add_v4_addrs() isn't properly integrated into the rest of IPv6 Neighbor Discovery code. Several of these shortcomings have been fixed over time, but add_v4_addrs() remains broken on several aspects. In particular, it doesn't send any Router Sollicitations, so the SLAAC process doesn't start until the interface receives a Router Advertisement. Also, add_v4_addrs() mostly ignores the address generation mode of the interface (/proc/sys/net/ipv6/conf/*/addr_gen_mode), thus breaking the IN6_ADDR_GEN_MODE_RANDOM and IN6_ADDR_GEN_MODE_STABLE_PRIVACY cases. Fix the situation by using add_v4_addrs() only in the specific scenario where the normal method would fail. That is, for interfaces that have all of the following characteristics: * run over IPv4, * transport IP packets directly, not Ethernet (that is, not gretap interfaces), * tunnel endpoint is INADDR_ANY (that is, 0), * device address generation mode is EUI64. In all other cases, revert back to the regular addrconf_addr_gen(). Also, remove the special case for ip6gre interfaces in add_v4_addrs(), since ip6gre devices now always use addrconf_addr_gen() instead. Note: This patch was originally applied as commit 183185a18ff9 ("gre: Fix IPv6 link-local address generation."). However, it was then reverted by commit fc486c2d060f ("Revert "gre: Fix IPv6 link-local address generation."") because it uncovered another bug that ended up breaking net/forwarding/ip6gre_custom_multipath_hash.sh. That other bug has now been fixed by commit 4d0ab3a6885e ("ipv6: Start path selection from the first nexthop"). Therefore we can now revive this GRE patch (no changes since original commit 183185a18ff9 ("gre: Fix IPv6 link-local address generation."). Fixes: e5dd729460ca ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") Signed-off-by: Guillaume Nault Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/a88cc5c4811af36007645d610c95102dccb360a6.1746225214.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94a6f6c204abb2b2dcd2ce287536cc924469cfb5 Author: Jakub Kicinski Date: Wed Apr 30 09:38:36 2025 -0700 virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable() [ Upstream commit 4397684a292a71fbc1e815c3e283f7490ddce5ae ] The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Acked-by: Jason Wang Fixes: e9f3962441c0 ("virtio_net: xsk: rx: support fill with xsk buffer") Link: https://patch.msgid.link/20250430163836.3029761-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit edd53ee790f3885bba157e99c79405b6aa1b78e5 Author: Xuan Zhuo Date: Tue Nov 12 09:29:24 2024 +0800 virtio_net: xsk: bind/unbind xsk for tx [ Upstream commit 21a4e3ce6dc7b0a3bc882ebe1cb921a40235ddb0 ] This patch implement the logic of bind/unbind xsk pool to sq and rq. Signed-off-by: Xuan Zhuo Acked-by: Jason Wang Link: https://patch.msgid.link/20241112012928.102478-10-xuanzhuo@linux.alibaba.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4397684a292a ("virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()") Signed-off-by: Sasha Levin commit 98cd7ed92753090a714f0802d4434314526fe61d Author: Cong Wang Date: Mon Apr 28 16:29:54 2025 -0700 sch_htb: make htb_deactivate() idempotent [ Upstream commit 3769478610135e82b262640252d90f6efb05be71 ] Alan reported a NULL pointer dereference in htb_next_rb_node() after we made htb_qlen_notify() idempotent. It turns out in the following case it introduced some regression: htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate() For htb_next_rb_node(), after calling the 1st htb_deactivate(), the clprio[prio]->ptr could be already set to NULL, which means htb_next_rb_node() is vulnerable here. For htb_deactivate(), although we checked qlen before calling it, in case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again which triggers the warning inside. To fix the issues here, we need to: 1) Make htb_deactivate() idempotent, that is, simply return if we already call it before. 2) Make htb_next_rb_node() safe against ptr==NULL. Many thanks to Alan for testing and for the reproducer. Fixes: 5ba8b837b522 ("sch_htb: make htb_qlen_notify() idempotent") Reported-by: Alan J. Wylie Signed-off-by: Cong Wang Link: https://patch.msgid.link/20250428232955.1740419-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5c3b8f05756b17c30b8272b63d80fba6b0c7934f Author: Heiko Carstens Date: Thu Apr 24 17:07:01 2025 +0200 s390/entry: Fix last breaking event handling in case of stack corruption [ Upstream commit ae952eea6f4a7e2193f8721a5366049946e012e7 ] In case of stack corruption stack_invalid() is called and the expectation is that register r10 contains the last breaking event address. This dependency is quite subtle and broke a couple of years ago without that anybody noticed. Fix this by getting rid of the dependency and read the last breaking event address from lowcore. Fixes: 56e62a737028 ("s390: convert to generic entry") Acked-by: Ilya Leoshkevich Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 2148d34371b06dac696c0497a98a6bf905a51650 Author: Wang Zhaolong Date: Wed Apr 30 11:16:23 2025 +0800 ksmbd: fix memory leak in parse_lease_state() [ Upstream commit eb4447bcce915b43b691123118893fca4f372a8f ] The previous patch that added bounds check for create lease context introduced a memory leak. When the bounds check fails, the function returns NULL without freeing the previously allocated lease_ctx_info structure. This patch fixes the issue by adding kfree(lreq) before returning NULL in both boundary check cases. Fixes: bab703ed8472 ("ksmbd: add bounds check for create lease context") Signed-off-by: Wang Zhaolong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ec334aaab74705cc515205e1da3cb369fdfd93cd Author: Eelco Chaudron Date: Tue May 6 16:28:54 2025 +0200 openvswitch: Fix unsafe attribute parsing in output_userspace() commit 6beb6835c1fbb3f676aebb51a5fee6b77fed9308 upstream. This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed. Fixes: ccb1352e76cf ("net: Add Open vSwitch kernel components.") Signed-off-by: Eelco Chaudron Acked-by: Ilya Maximets Acked-by: Aaron Conole Link: https://patch.msgid.link/0bd65949df61591d9171c0dc13e42cea8941da10.1746541734.git.echaudro@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9e9841e232b51171ddf3bc4ee517d5d28dc8cad6 Author: Sean Heelan Date: Tue May 6 22:04:52 2025 +0900 ksmbd: Fix UAF in __close_file_table_ids commit 36991c1ccde2d5a521577c448ffe07fcccfe104d upstream. A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this. The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock. Cc: stable@vger.kernel.org Signed-off-by: Sean Heelan Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d62ba16563a86aae052f96d270b3b6f78fca154c Author: Norbert Szetei Date: Fri May 2 08:21:58 2025 +0900 ksmbd: prevent out-of-bounds stream writes by validating *pos commit 0ca6df4f40cf4c32487944aaf48319cb6c25accc upstream. ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned. Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c57301e332cc413fe0a7294a90725f4e21e9549d Author: Namjae Jeon Date: Wed Apr 30 11:18:28 2025 +0900 ksmbd: prevent rename with empty string commit 53e3e5babc0963a92d856a5ec0ce92c59f54bc12 upstream. Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1b7b1cbc6e730f3a49428c5d0f917fcc92a5e6f7 Author: Marc Kleine-Budde Date: Fri May 2 16:13:45 2025 +0200 can: rockchip_canfd: rkcanfd_remove(): fix order of unregistration calls commit 037ada7a3181300218e4fd78bef6a741cfa7f808 upstream. If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-2-59a9b131589d@pengutronix.de Reviewed-by: Markus Schneider-Pargmann Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 12ef60f1b99ca63af8a65dabbbdf63c030eb1232 Author: Marc Kleine-Budde Date: Fri May 2 16:13:44 2025 +0200 can: mcp251xfd: mcp251xfd_remove(): fix order of unregistration calls commit 84f5eb833f53ae192baed4cfb8d9eaab43481fc9 upstream. If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. With the mcp251xfd driver the removal of the module causes the following warning: | WARNING: CPU: 0 PID: 352 at net/core/dev.c:7342 __netif_napi_del_locked+0xc8/0xd8 as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-1-59a9b131589d@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit c488f8b53e156d6dcc0514ef0afa3a33376b8f9e Author: Niklas Schnelle Date: Wed Apr 30 15:26:19 2025 +0200 s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs commit 05a2538f2b48500cf4e8a0a0ce76623cc5bafcf1 upstream. With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") the code to ignore power off of a PF that has child VFs was changed from a direct return to a goto to the unlock and pci_dev_put() section. The change however left the existing pci_dev_put() untouched resulting in a doubple put. This can subsequently cause a use after free if the struct pci_dev is released in an unexpected state. Fix this by removing the extra pci_dev_put(). Cc: stable@vger.kernel.org Fixes: bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") Signed-off-by: Niklas Schnelle Reviewed-by: Gerd Bayer Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit afa5cdce062a246ec3b465082d87e52768771667 Author: Alex Williamson Date: Fri May 2 16:40:31 2025 -0600 vfio/pci: Align huge faults to order commit c1d9dac0db168198b6f63f460665256dedad9b6e upstream. The vfio-pci huge_fault handler doesn't make any attempt to insert a mapping containing the faulting address, it only inserts mappings if the faulting address and resulting pfn are aligned. This works in a lot of cases, particularly in conjunction with QEMU where DMA mappings linearly fault the mmap. However, there are configurations where we don't get that linear faulting and pages are faulted on-demand. The scenario reported in the bug below is such a case, where the physical address width of the CPU is greater than that of the IOMMU, resulting in a VM where guest firmware has mapped device MMIO beyond the address width of the IOMMU. In this configuration, the MMIO is faulted on demand and tracing indicates that occasionally the faults generate a VM_FAULT_OOM. Given the use case, this results in a "error: kvm run failed Bad address", killing the VM. The host is not under memory pressure in this test, therefore it's suspected that VM_FAULT_OOM is actually the result of a NULL return from __pte_offset_map_lock() in the get_locked_pte() path from insert_pfn(). This suggests a potential race inserting a pte concurrent to a pmd, and maybe indicates some deficiency in the mm layer properly handling such a case. Nevertheless, Peter noted the inconsistency of vfio-pci's huge_fault handler where our mapping granularity depends on the alignment of the faulting address relative to the order rather than aligning the faulting address to the order to more consistently insert huge mappings. This change not only uses the page tables more consistently and efficiently, but as any fault to an aligned page results in the same mapping, the race condition suspected in the VM_FAULT_OOM is avoided. Reported-by: Adolfo Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220057 Fixes: 09dfc8a5f2ce ("vfio/pci: Fallback huge faults for unaligned pfn") Cc: stable@vger.kernel.org Tested-by: Adolfo Co-developed-by: Peter Xu Signed-off-by: Peter Xu Link: https://lore.kernel.org/r/20250502224035.3183451-1-alex.williamson@redhat.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 9423f6da825172b8dc60d4688ed3d147291c3be9 Author: Veerendranath Jakkam Date: Thu Apr 24 18:01:42 2025 +0530 wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation commit 023c1f2f0609218103cbcb48e0104b144d4a16dc upstream. Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211_defrag_mle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer. To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset. Cc: stable@vger.kernel.org Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses") Signed-off-by: Veerendranath Jakkam Link: https://patch.msgid.link/20250424-fix_mle_defragmentation_oob_access-v1-1-84412a1743fa@quicinc.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit be54b750c333a9db7c3b3686846bb06b07b011fe Author: Niklas Schnelle Date: Wed Apr 30 15:26:18 2025 +0200 s390/pci: Fix missing check for zpci_create_device() error return commit 42420c50c68f3e95e90de2479464f420602229fc upstream. The zpci_create_device() function returns an error pointer that needs to be checked before dereferencing it as a struct zpci_dev pointer. Add the missing check in __clp_add() where it was missed when adding the scan_list in the fixed commit. Simply not adding the device to the scan list results in the previous behavior. Cc: stable@vger.kernel.org Fixes: 0467cdde8c43 ("s390/pci: Sort PCI functions prior to creating virtual busses") Signed-off-by: Niklas Schnelle Reviewed-by: Gerd Bayer Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit e0a8e3ca07be66064056efa97c79eebfc0756a74 Author: Marc Kleine-Budde Date: Fri May 2 16:13:46 2025 +0200 can: mcan: m_can_class_unregister(): fix order of unregistration calls commit 0713a1b3276b98c7dafbeefef00d7bc3a9119a84 upstream. If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-3-59a9b131589d@pengutronix.de Reviewed-by: Markus Schneider-Pargmann Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 14ee85b74807ab05c897094ab194bf3b50080d20 Author: Cristian Marussi Date: Mon Mar 10 17:58:00 2025 +0000 firmware: arm_scmi: Fix timeout checks on polling path commit c23c03bf1faa1e76be1eba35bad6da6a2a7c95ee upstream. Polling mode transactions wait for a reply busy-looping without holding a spinlock, but currently the timeout checks are based only on elapsed time: as a result we could hit a false positive whenever our busy-looping thread is pre-empted and scheduled out for a time greater than the polling timeout. Change the checks at the end of the busy-loop to make sure that the polling wasn't indeed successful or an out-of-order reply caused the polling to be forcibly terminated. Fixes: 31d2f803c19c ("firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag") Reported-by: Huangjie Closes: https://lore.kernel.org/arm-scmi/20250123083323.2363749-1-jackhuang021@gmail.com/ Signed-off-by: Cristian Marussi Cc: stable@vger.kernel.org # 5.18.x Message-Id: <20250310175800.1444293-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit fe3da1bfd8d409b17aec47efc2f44b8d050a6521 Author: Wojciech Dubowik Date: Thu Apr 24 11:59:14 2025 +0200 arm64: dts: imx8mm-verdin: Link reg_usdhc2_vqmmc to usdhc2 commit 5591ce0069ddda97cdbbea596bed53e698f399c2 upstream. Define vqmmc regulator-gpio for usdhc2 with vin-supply coming from LDO5. Without this definition LDO5 will be powered down, disabling SD card after bootup. This has been introduced in commit f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5"). Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Fixes: f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5") Tested-by: Manuel Traut Reviewed-by: Philippe Schenker Tested-by: Francesco Dolcini Reviewed-by: Francesco Dolcini Cc: stable@vger.kernel.org Signed-off-by: Wojciech Dubowik Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit ff7d691921c7a51ea8bb90fd8ce4a06247764e5e Author: Qu Wenruo Date: Fri Jan 17 09:09:34 2025 +1030 Revert "btrfs: canonicalize the device path before adding it" commit 8fb1dcbbcc1ffe6ed7cf3f0f96d2737491dd1fbf upstream. This reverts commit 7e06de7c83a746e58d4701e013182af133395188. Commit 7e06de7c83a7 ("btrfs: canonicalize the device path before adding it") tries to make btrfs to use "/dev/mapper/*" name first, then any filename inside "/dev/" as the device path. This is mostly fine when there is only the root namespace involved, but when multiple namespace are involved, things can easily go wrong for the d_path() usage. As d_path() returns a file path that is namespace dependent, the resulted string may not make any sense in another namespace. Furthermore, the "/dev/" prefix checks itself is not reliable, one can still make a valid initramfs without devtmpfs, and fill all needed device nodes manually. Overall the userspace has all its might to pass whatever device path for mount, and we are not going to win the war trying to cover every corner case. So just revert that commit, and do no extra d_path() based file path sanity check. CC: stable@vger.kernel.org # 6.12+ Link: https://lore.kernel.org/linux-fsdevel/20250115185608.GA2223535@zen.localdomain/ Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 61e0fc3312309867e5a3495329dad0286d2a5703 Author: Max Kellermann Date: Tue Apr 29 01:09:33 2025 +0200 fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio() commit bbfe756dc3062c1e934f06e5ba39c239aa953b92 upstream. If bio_add_folio() fails (because it is full), erofs_fileio_scan_folio() needs to submit the I/O request via erofs_fileio_rq_submit() and allocate a new I/O request with an empty `struct bio`. Then it retries the bio_add_folio() call. However, at this point, erofs_onlinefolio_split() has already been called which increments `folio->private`; the retry will call erofs_onlinefolio_split() again, but there will never be a matching erofs_onlinefolio_end() call. This leaves the folio locked forever and all waiters will be stuck in folio_wait_bit_common(). This bug has been added by commit ce63cb62d794 ("erofs: support unencoded inodes for fileio"), but was practically unreachable because there was room for 256 folios in the `struct bio` - until commit 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which reduced the array capacity to 16 folios. It was now trivial to trigger the bug by manually invoking readahead from userspace, e.g.: posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED); This should be fixed by invoking erofs_onlinefolio_split() only after bio_add_folio() has succeeded. This is safe: asynchronous completions invoking erofs_onlinefolio_end() will not unlock the folio because erofs_fileio_scan_folio() is still holding a reference to be released by erofs_onlinefolio_end() at the end. Fixes: ce63cb62d794 ("erofs: support unencoded inodes for fileio") Fixes: 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann Reviewed-by: Gao Xiang Tested-by: Hongbo Li Link: https://lore.kernel.org/r/20250428230933.3422273-1-max.kellermann@ionos.com Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit b32411f0459d2e069d9ab7b989d11bf4bf72524b Author: Dan Carpenter Date: Wed Apr 30 11:05:54 2025 +0300 dm: add missing unlock on in dm_keyslot_evict() commit 650266ac4c7230c89bcd1307acf5c9c92cfa85e2 upstream. We need to call dm_put_live_table() even if dm_get_live_table() returns NULL. Fixes: 9355a9eb21a5 ("dm: support key eviction from keyslot managers of underlying devices") Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Dan Carpenter Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman