kernel/linux.git, branch v6.1.143

Linux 6.1.143

2025-07-06T08:58:04+00:00

Link: https://lore.kernel.org/r/20250703143939.370927276@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Hardik Garg Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Miguel Ojeda Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman

ARM: 9354/1: ptrace: Use bitfield helpers

2025-07-06T08:58:04+00:00

commit b36e78b216e632d90138751e4ff80044de303656 upstream. The isa_mode() macro extracts two fields, and recombines them into a single value. Make this more obvious by using the FIELD_GET() helper, and shifting the result into its final resting place. Signed-off-by: Geert Uytterhoeven Reviewed-by: Oleg Nesterov Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman

arm64: Restrict pagetable teardown to avoid false warning

2025-07-06T08:58:04+00:00

commit 650768c512faba8070bf4cfbb28c95eb5cd203f3 upstream. Commit 9c006972c3fe ("arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()") removes the pxd_present() checks because the caller checks pxd_present(). But, in case of vmap_try_huge_pud(), the caller only checks pud_present(); pud_free_pmd_page() recurses on each pmd through pmd_free_pte_page(), wherein the pmd may be none. Thus it is possible to hit a warning in the latter, since pmd_none => !pmd_table(). Thus, add a pmd_present() check in pud_free_pmd_page(). This problem was found by code inspection. Fixes: 9c006972c3fe ("arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()") Cc: stable@vger.kernel.org Reported-by: Ryan Roberts Acked-by: David Hildenbrand Signed-off-by: Dev Jain Reviewed-by: Catalin Marinas Reviewed-by: Anshuman Khandual Reviewed-by: Ryan Roberts Link: https://lore.kernel.org/r/20250527082633.61073-1-dev.jain@arm.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

firmware: arm_scmi: Ensure that the message-id supports fastchannel

2025-07-06T08:58:04+00:00

commit 94a263f981a3fa3d93f65c31e0fed0756736be43 upstream. Currently the perf and powercap protocol relies on the protocol domain attributes, which just ensures that one fastchannel per domain, before instantiating fastchannels for all possible message-ids. Fix this by ensuring that each message-id supports fastchannel before initialization. Logs: | scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging | scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging | scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging CC: stable@vger.kernel.org Reported-by: Johan Hovold Closes: https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@hovoldconsulting.com/ Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support") Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Sibi Sankar [Cristian: Modified the condition checked to establish support or not] Signed-off-by: Cristian Marussi Message-Id: <20250429141108.406045-2-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman

firmware: arm_scmi: Add a common helper to check if a message is supported

2025-07-06T08:58:04+00:00

commit 637b6d6cae9c42db5a9525da67c991294924d2cd upstream. A common helper is provided to check if a specific protocol message is supported or not. Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20240212123233.1230090-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman

io_uring/kbuf: account ring io_buffer_list memory

2025-07-06T08:58:04+00:00

Commit 475a8d30371604a6363da8e304a608a5959afc40 upstream. Follow the non-ringed pbuf struct io_buffer_list allocations and account it against the memcg. There is low chance of that being an actual problem as ring provided buffer should either pin user memory or allocate it, which is already accounted. Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3985218b50d341273cafff7234e1a7e6d0db9808.1747150490.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

nvme: always punt polled uring_cmd end_io work to task_work

2025-07-06T08:58:04+00:00

Commit 9ce6c9875f3e995be5fd720b65835291f8a609b1 upstream. Currently NVMe uring_cmd completions will complete locally, if they are polled. This is done because those completions are always invoked from task context. And while that is true, there's no guarantee that it's invoked under the right ring context, or even task. If someone does NVMe passthrough via multiple threads and with a limited number of poll queues, then ringA may find completions from ringB. For that case, completing the request may not be sound. Always just punt the passthrough completions via task_work, which will redirect the completion, if needed. Cc: stable@vger.kernel.org Fixes: 585079b6e425 ("nvme: wire up async polling for io passthrough commands") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

Revert "ipv6: save dontfrag in cork"

2025-07-06T08:58:04+00:00

This reverts commit 4f809be95d9f3db13d31c574b8764c8d429f0c3b which is commit a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a upstream. A regression was introduced when backporting this to the stable kernels without applying previous commits in this series. When sending IPv6 UDP packets larger than MTU, EMSGSIZE was returned instead of fragmenting the packets as expected. As there is no compelling reason for this commit to be present in the stable kernels it should be reverted. Signed-off-by: Brett A C Sheffield Signed-off-by: Greg Kroah-Hartman

x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c

2025-07-06T08:58:04+00:00

commit f710202b2a45addea3dcdcd862770ecbaf6597ef upstream. After commit c104c16073b7 ("Kunit to check the longest symbol length"), there is a warning when building with clang because there is now a definition of unlikely from compiler.h in tools/include/linux, which conflicts with the one in the instruction decoder selftest: arch/x86/tools/insn_decoder_test.c:15:9: warning: 'unlikely' macro redefined [-Wmacro-redefined] Remove the second unlikely() definition, as it is no longer necessary, clearing up the warning. Fixes: c104c16073b7 ("Kunit to check the longest symbol length") Signed-off-by: Nathan Chancellor Signed-off-by: Ingo Molnar Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20250318-x86-decoder-test-fix-unlikely-redef-v1-1-74c84a7bf05b@kernel.org Signed-off-by: Greg Kroah-Hartman

Kunit to check the longest symbol length

2025-07-06T08:58:03+00:00

commit c104c16073b7fdb3e4eae18f66f4009f6b073d6f upstream. The longest length of a symbol (KSYM_NAME_LEN) was increased to 512 in the reference [1]. This patch adds kunit test suite to check the longest symbol length. These tests verify that the longest symbol length defined is supported. This test can also help other efforts for longer symbol length, like [2]. The test suite defines one symbol with the longest possible length. The first test verify that functions with names of the created symbol, can be called or not. The second test, verify that the symbols are created (or not) in the kernel symbol table. [1] https://lore.kernel.org/lkml/20220802015052.10452-6-ojeda@kernel.org/ [2] https://lore.kernel.org/lkml/20240605032120.3179157-1-song@kernel.org/ Link: https://lore.kernel.org/r/20250302221518.76874-1-sergio.collado@gmail.com Tested-by: Martin Rodriguez Reboredo Reviewed-by: Shuah Khan Reviewed-by: Rae Moar Signed-off-by: Sergio González Collado Link: https://github.com/Rust-for-Linux/linux/issues/504 Reviewed-by: Rae Moar Acked-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman