kernel/linux.git, branch v5.4.284

Linux 5.4.284

2024-09-12T09:03:57+00:00

Link: https://lore.kernel.org/r/20240910092545.737864202@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20240911130518.626277627@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

Revert "parisc: Use irq_enter_rcu() to fix warning at kernel/context_tracking.c:367"

2024-09-12T09:03:57+00:00

This reverts commit b62f96647b1e78721ef9b616ba8cce90aecbb3b0 which is commit 73cb4a2d8d7e0259f94046116727084f21e4599f upstream. It breaks the build on parisc systems, so revert it. Reported-by: Guenter Roeck Link: https://lore.kernel.org/r/092aa55c-0538-41e5-8ed0-d0a96b06f32e@roeck-us.net Reported-by: Helge Deller Link: https://lore.kernel.org/r/72b133a6-c221-4906-9184-30b4e6ee4260@gmx.de Signed-off-by: Greg Kroah-Hartman

cx82310_eth: fix error return code in cx82310_bind()

2024-09-12T09:03:57+00:00

commit cfbaa8b33e022aca62a3f2815ffbc02874d4cb8b upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: ca139d76b0d9 ("cx82310_eth: re-enable ethernet mode after router reboot") Reported-by: Hulk Robot Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1605247627-15385-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket

2024-09-12T09:03:57+00:00

commit 626dfed5fa3bfb41e0dffd796032b555b69f9cde upstream. When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request(). Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect") Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind") Co-developed-by: Lex Siegel Signed-off-by: Lex Siegel Signed-off-by: Daniel Borkmann Cc: Neil Brown Cc: Trond Myklebust Cc: Anna Schumaker Link: https://github.com/cilium/cilium/issues/33395 Link: https://lore.kernel.org/bpf/171374175513.12877.8993642908082014881@noble.neil.brown.name Link: https://patch.msgid.link/9069ec1d59e4b2129fc23433349fd5580ad43921.1720075070.git.daniel@iogearbox.net Signed-off-by: Paolo Abeni Signed-off-by: Hugo SIMELIERE Signed-off-by: Greg Kroah-Hartman

rtmutex: Drop rt_mutex::wait_lock before scheduling

2024-09-12T09:03:57+00:00

commit d33d26036a0274b472299d7dcdaa5fb34329f91b upstream. rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ] Fixes: 3d5c9340d194 ("rtmutex: Handle deadlock detection smarter") Signed-off-by: Roland Xu Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/ME0P300MB063599BEF0743B8FA339C2CECC802@ME0P300MB0635.AUSP300.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman

drm/i915/fence: Mark debug_fence_free() with __maybe_unused

2024-09-12T09:03:57+00:00

[ Upstream commit f99999536128b14b5d765a9982763b5134efdd79 ] When debug_fence_free() is unused (CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:118:20: error: unused function 'debug_fence_free' [-Werror,-Wunused-function] 118 | static inline void debug_fence_free(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~ Fix this by marking debug_fence_free() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: fc1584059d6c ("drm/i915: Integrate i915_sw_fence with debugobjects") Signed-off-by: Andy Shevchenko Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20240829155950.1141978-3-andriy.shevchenko@linux.intel.com Signed-off-by: Jani Nikula (cherry picked from commit 8be4dce5ea6f2368cc25edc71989c4690fa66964) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin

drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unused

2024-09-12T09:03:56+00:00

[ Upstream commit fcd9e8afd546f6ced378d078345a89bf346d065e ] When debug_fence_init_onstack() is unused (CONFIG_DRM_I915_SELFTEST=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:97:20: error: unused function 'debug_fence_init_onstack' [-Werror,-Wunused-function] 97 | static inline void debug_fence_init_onstack(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~~~~~~~~~ Fix this by marking debug_fence_init_onstack() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: 214707fc2ce0 ("drm/i915/selftests: Wrap a timer into a i915_sw_fence") Signed-off-by: Andy Shevchenko Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20240829155950.1141978-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jani Nikula (cherry picked from commit 5bf472058ffb43baf6a4cdfe1d7f58c4c194c688) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin

nvmet-tcp: fix kernel crash if commands allocation fails

2024-09-12T09:03:56+00:00

[ Upstream commit 5572a55a6f830ee3f3a994b6b962a5c327d28cb3 ] If the commands allocation fails in nvmet_tcp_alloc_cmds() the kernel crashes in nvmet_tcp_release_queue_work() because of a NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Fix the bug by setting queue->nr_cmds to zero in case nvmet_tcp_alloc_cmd() fails. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Signed-off-by: Maurizio Lombardi Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin

arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry

2024-09-12T09:03:56+00:00

[ Upstream commit 2488444274c70038eb6b686cba5f1ce48ebb9cdd ] In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility. Reviewed-by: Gavin Shan Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20240529133446.28446-13-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

arm64: acpi: Move get_cpu_for_acpi_id() to a header

2024-09-12T09:03:56+00:00

[ Upstream commit 8d34b6f17b9ac93faa2791eb037dcb08bdf755de ] ACPI identifies CPUs by UID. get_cpu_for_acpi_id() maps the ACPI UID to the Linux CPU number. The helper to retrieve this mapping is only available in arm64's NUMA code. Move it to live next to get_acpi_id_for_cpu(). Signed-off-by: James Morse Reviewed-by: Jonathan Cameron Reviewed-by: Gavin Shan Tested-by: Miguel Luis Tested-by: Vishnu Pajjuri Tested-by: Jianyong Wu Signed-off-by: Russell King (Oracle) Acked-by: Hanjun Guo Signed-off-by: Jonathan Cameron Reviewed-by: Lorenzo Pieralisi Link: https://lore.kernel.org/r/20240529133446.28446-12-Jonathan.Cameron@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin