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

FAILED: patch "[PATCH] selftests: mptcp: join: properly kill background tasks" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 852b644acbce1529307a4bb283752c4e77b5cda7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112001-gauging-hurdle-297f@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 852b644acbce1529307a4bb283752c4e77b5cda7 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 10 Nov 2025 19:23:45 +0100 Subject: [PATCH] selftests: mptcp: join: properly kill background tasks The 'run_tests' function is executed in the background, but killing its associated PID would not kill the children tasks running in the background. To properly kill all background tasks, 'kill -- -PID' could be used, but this requires kill from procps-ng. Instead, all children tasks are listed using 'ps', and 'kill' is called with all PIDs of this group. Fixes: 31ee4ad86afd ("selftests: mptcp: join: stop transfer when check is done (part 1)") Cc: stable(a)vger.kernel.org Fixes: 04b57c9e096a ("selftests: mptcp: join: stop transfer when check is done (part 2)") Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251110-net-mptcp-sft-join-unstable-v1-6-a4332c71… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index 01273abfdc89..41503c241989 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -3831,7 +3831,7 @@ userspace_tests() chk_mptcp_info subflows 0 subflows 0 chk_subflows_total 1 1 kill_events_pids - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid fi # userspace pm create destroy subflow @@ -3859,7 +3859,7 @@ userspace_tests() chk_mptcp_info subflows 0 subflows 0 chk_subflows_total 1 1 kill_events_pids - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid fi # userspace pm create id 0 subflow @@ -3880,7 +3880,7 @@ userspace_tests() chk_mptcp_info subflows 1 subflows 1 chk_subflows_total 2 2 kill_events_pids - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid fi # userspace pm remove initial subflow @@ -3904,7 +3904,7 @@ userspace_tests() chk_mptcp_info subflows 1 subflows 1 chk_subflows_total 1 1 kill_events_pids - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid fi # userspace pm send RM_ADDR for ID 0 @@ -3930,7 +3930,7 @@ userspace_tests() chk_mptcp_info subflows 1 subflows 1 chk_subflows_total 1 1 kill_events_pids - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid fi } @@ -3960,7 +3960,7 @@ endpoint_tests() pm_nl_add_endpoint $ns2 10.0.2.2 flags signal pm_nl_check_endpoint "modif is allowed" \ $ns2 10.0.2.2 id 1 flags signal - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid fi if reset_with_tcp_filter "delete and re-add" ns2 10.0.3.2 REJECT OUTPUT && @@ -4015,7 +4015,7 @@ endpoint_tests() chk_mptcp_info subflows 3 subflows 3 done - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid kill_events_pids chk_evt_nr ns1 MPTCP_LIB_EVENT_LISTENER_CREATED 1 @@ -4089,7 +4089,7 @@ endpoint_tests() wait_mpj $ns2 chk_subflow_nr "after re-re-add ID 0" 3 chk_mptcp_info subflows 3 subflows 3 - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid kill_events_pids chk_evt_nr ns1 MPTCP_LIB_EVENT_LISTENER_CREATED 1 @@ -4137,7 +4137,7 @@ endpoint_tests() wait_mpj $ns2 pm_nl_add_endpoint $ns1 10.0.3.1 id 2 flags signal wait_mpj $ns2 - mptcp_lib_kill_wait $tests_pid + mptcp_lib_kill_group_wait $tests_pid join_syn_tx=3 join_connect_err=1 \ chk_join_nr 2 2 2 diff --git a/tools/testing/selftests/net/mptcp/mptcp_lib.sh b/tools/testing/selftests/net/mptcp/mptcp_lib.sh index d62e653d48b0..f4388900016a 100644 --- a/tools/testing/selftests/net/mptcp/mptcp_lib.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_lib.sh @@ -350,6 +350,27 @@ mptcp_lib_kill_wait() { wait "${1}" 2>/dev/null } +# $1: PID +mptcp_lib_pid_list_children() { + local curr="${1}" + # evoke 'ps' only once + local pids="${2:-"$(ps o pid,ppid)"}" + + echo "${curr}" + + local pid + for pid in $(echo "${pids}" | awk "\$2 == ${curr} { print \$1 }"); do + mptcp_lib_pid_list_children "${pid}" "${pids}" + done +} + +# $1: PID +mptcp_lib_kill_group_wait() { + # Some users might not have procps-ng: cannot use "kill -- -PID" + mptcp_lib_pid_list_children "${1}" | xargs -r kill &>/dev/null + wait "${1}" 2>/dev/null +} + # $1: IP address mptcp_lib_is_v6() { [ -z "${1##*:*}" ]

1 day, 16 hours

2
1
0 0

FAILED: patch "[PATCH] mptcp: fix duplicate reset on fastclose" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x ae155060247be8dcae3802a95bd1bdf93ab3215d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025112433-making-debatable-abfe@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ae155060247be8dcae3802a95bd1bdf93ab3215d Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Tue, 18 Nov 2025 08:20:24 +0100 Subject: [PATCH] mptcp: fix duplicate reset on fastclose The CI reports sporadic failures of the fastclose self-tests. The root cause is a duplicate reset, not carrying the relevant MPTCP option. In the failing scenario the bad reset is received by the peer before the fastclose one, preventing the reception of the latter. Indeed there is window of opportunity at fastclose time for the following race: mptcp_do_fastclose __mptcp_close_ssk __tcp_close() tcp_set_state() [1] tcp_send_active_reset() [2] After [1] the stack will send reset to in-flight data reaching the now closed port. Such reset may race with [2]. Address the issue explicitly sending a single reset on fastclose before explicitly moving the subflow to close status. Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") Cc: stable(a)vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/596 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Geliang Tang <geliang(a)kernel.org> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-6-806d37… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index c59246c1fde6..a70267a74e3c 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2409,7 +2409,6 @@ bool __mptcp_retransmit_pending_data(struct sock *sk) /* flags for __mptcp_close_ssk() */ #define MPTCP_CF_PUSH BIT(1) -#define MPTCP_CF_FASTCLOSE BIT(2) /* be sure to send a reset only if the caller asked for it, also * clean completely the subflow status when the subflow reaches @@ -2420,7 +2419,7 @@ static void __mptcp_subflow_disconnect(struct sock *ssk, unsigned int flags) { if (((1 << ssk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN)) || - (flags & MPTCP_CF_FASTCLOSE)) { + subflow->send_fastclose) { /* The MPTCP code never wait on the subflow sockets, TCP-level * disconnect should never fail */ @@ -2467,14 +2466,8 @@ static void __mptcp_close_ssk(struct sock *sk, struct sock *ssk, lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); - if ((flags & MPTCP_CF_FASTCLOSE) && !__mptcp_check_fallback(msk)) { - /* be sure to force the tcp_close path - * to generate the egress reset - */ - ssk->sk_lingertime = 0; - sock_set_flag(ssk, SOCK_LINGER); - subflow->send_fastclose = 1; - } + if (subflow->send_fastclose && ssk->sk_state != TCP_CLOSE) + tcp_set_state(ssk, TCP_CLOSE); need_push = (flags & MPTCP_CF_PUSH) && __mptcp_retransmit_pending_data(sk); if (!dispose_it) { @@ -2779,9 +2772,26 @@ static void mptcp_do_fastclose(struct sock *sk) struct mptcp_sock *msk = mptcp_sk(sk); mptcp_set_state(sk, TCP_CLOSE); - mptcp_for_each_subflow_safe(msk, subflow, tmp) - __mptcp_close_ssk(sk, mptcp_subflow_tcp_sock(subflow), - subflow, MPTCP_CF_FASTCLOSE); + + /* Explicitly send the fastclose reset as need */ + if (__mptcp_check_fallback(msk)) + return; + + mptcp_for_each_subflow_safe(msk, subflow, tmp) { + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + + lock_sock(ssk); + + /* Some subflow socket states don't allow/need a reset.*/ + if ((1 << ssk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE)) + goto unlock; + + subflow->send_fastclose = 1; + tcp_send_active_reset(ssk, ssk->sk_allocation, + SK_RST_REASON_TCP_ABORT_ON_CLOSE); +unlock: + release_sock(ssk); + } } static void mptcp_worker(struct work_struct *work)

1 day, 16 hours

2
1
0 0

[PATCH v3] drm/msm: add PERFCTR_CNTL to ifpc_reglist

by Anna Maniscalco

Previously this register would become 0 after IFPC took place which broke all usages of counters. Fixes: a6a0157cc68e ("drm/msm/a6xx: Enable IFPC on Adreno X1-85") Cc: stable(a)vger.kernel.org Signed-off-by: Anna Maniscalco <anna.maniscalco2000(a)gmail.com> Reviewed-by: Akhil P Oommen <akhilpo(a)oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> --- Changes in v3: - Added missing Cc: stable to commit - Collected Rb tags - Link to v2: https://lore.kernel.org/r/20251126-ifpc_counters-v2-1-b798bc433eff@gmail.com Changes in v2: - Added Fixes tag - Link to v1: https://lore.kernel.org/r/20251126-ifpc_counters-v1-1-f2d5e7048032@gmail.com --- drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c index 29107b362346..b731491dc522 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c @@ -1392,6 +1392,7 @@ static const u32 a750_ifpc_reglist_regs[] = { REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE(2), REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE(3), REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE(4), + REG_A6XX_RBBM_PERFCTR_CNTL, REG_A6XX_TPL1_NC_MODE_CNTL, REG_A6XX_SP_NC_MODE_CNTL, REG_A6XX_CP_DBG_ECO_CNTL, --- base-commit: 7bc29d5fb6faff2f547323c9ee8d3a0790cd2530 change-id: 20251126-ifpc_counters-e8d53fa3252e Best regards, -- Anna Maniscalco <anna.maniscalco2000(a)gmail.com>

1 day, 16 hours

1
0
0 0

[PATCH 5.10] xfs: fix intermittent hang during quotacheck

by Alexey Panov

From: "Darrick J. Wong" <djwong(a)kernel.org> [ Upstream commit f0c2d7d2abca24d19831c99edea458704fac8087 ] Every now and then, I see the following hang during mount time quotacheck when running fstests. Turning on KASAN seems to make it happen somewhat more frequently. I've edited the backtrace for brevity. XFS (sdd): Quotacheck needed: Please wait. XFS: Assertion failed: bp->b_flags & _XBF_DELWRI_Q, file: fs/xfs/xfs_buf.c, line: 2411 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1831409 at fs/xfs/xfs_message.c:104 assfail+0x46/0x4a [xfs] CPU: 0 PID: 1831409 Comm: mount Tainted: G W 5.19.0-rc6-xfsx #rc6 09911566947b9f737b036b4af85e399e4b9aef64 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:assfail+0x46/0x4a [xfs] Code: a0 8f 41 a0 e8 45 fe ff ff 8a 1d 2c 36 10 00 80 fb 01 76 0f 0f b6 f3 48 c7 c7 c0 f0 4f a0 e8 10 f0 02 e1 80 e3 01 74 02 0f 0b <0f> 0b 5b c3 48 8d 45 10 48 89 e2 4c 89 e6 48 89 1c 24 48 89 44 24 RSP: 0018:ffffc900078c7b30 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880099ac000 RCX: 000000007fffffff RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa0418fa0 RBP: ffff8880197bc1c0 R08: 0000000000000000 R09: 000000000000000a R10: 000000000000000a R11: f000000000000000 R12: ffffc900078c7d20 R13: 00000000fffffff5 R14: ffffc900078c7d20 R15: 0000000000000000 FS: 00007f0449903800(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005610ada631f0 CR3: 0000000014dd8002 CR4: 00000000001706f0 Call Trace: <TASK> xfs_buf_delwri_pushbuf+0x150/0x160 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] xfs_qm_flush_one+0xd6/0x130 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] xfs_qm_dquot_walk.isra.0+0x109/0x1e0 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] xfs_qm_quotacheck+0x319/0x490 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] xfs_qm_mount_quotas+0x65/0x2c0 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] xfs_mountfs+0x6b5/0xab0 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] xfs_fs_fill_super+0x781/0x990 [xfs 4561f5b32c9bfb874ec98d58d0719464e1f87368] get_tree_bdev+0x175/0x280 vfs_get_tree+0x1a/0x80 path_mount+0x6f5/0xaa0 __x64_sys_mount+0x103/0x140 do_syscall_64+0x2b/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 I /think/ this can happen if xfs_qm_flush_one is racing with xfs_qm_dquot_isolate (i.e. dquot reclaim) when the second function has taken the dquot flush lock but xfs_qm_dqflush hasn't yet locked the dquot buffer, let alone queued it to the delwri list. In this case, flush_one will fail to get the dquot flush lock, but it can lock the incore buffer, but xfs_buf_delwri_pushbuf will then trip over this ASSERT, which checks that the buffer isn't on a delwri list. The hang results because the _delwri_submit_buffers ignores non DELWRI_Q buffers, which means that xfs_buf_iowait waits forever for an IO that has not yet been scheduled. AFAICT, a reasonable solution here is to detect a dquot buffer that is not on a DELWRI list, drop it, and return -EAGAIN to try the flush again. It's not /that/ big of a deal if quotacheck writes the dquot buffer repeatedly before we even set QUOTA_CHKD. Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Signed-off-by: Alexey Panov <apanov(a)astralinux.ru> --- Tested with the syzkaller reproducer for https://syzkaller.appspot.com/bug?extid=3ae67535b07c92aa02fd: the issue triggers on vanilla v5.10.y and no longer reproduces with this patch applied. fs/xfs/xfs_qm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c index 3c17e0c0f816..907819e7873e 100644 --- a/fs/xfs/xfs_qm.c +++ b/fs/xfs/xfs_qm.c @@ -1245,6 +1245,13 @@ xfs_qm_flush_one( error = -EINVAL; goto out_unlock; } + + if (!(bp->b_flags & _XBF_DELWRI_Q)) { + error = -EAGAIN; + xfs_buf_relse(bp); + goto out_unlock; + } + xfs_buf_unlock(bp); xfs_buf_delwri_pushbuf(bp, buffer_list); -- 2.39.5

1 day, 17 hours

1
0
0 0

[PATCH] drm/i915/gem: NULL-initialize the eb->vma[].vma pointers in gem_do_execbuffer

by Krzysztof Niemiec

Initialize eb->vma[].vma pointers to NULL when the eb structure is first set up. During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer. If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail. In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is nullified, which is a source of a NULL deref bug described in [1]. When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being nullified as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15062 Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf") Reported-by: Gangmin Kim <km.kim1503(a)gmail.com> Cc: <stable(a)vger.kernel.org> # 5.16.x Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec(a)intel.com> --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 27 ++++++------------- 1 file changed, 8 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index b057c2fa03a4..02120203af55 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -951,13 +951,13 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) vma = eb_lookup_vma(eb, eb->exec[i].handle); if (IS_ERR(vma)) { err = PTR_ERR(vma); - goto err; + return err; } err = eb_validate_vma(eb, &eb->exec[i], vma); if (unlikely(err)) { i915_vma_put(vma); - goto err; + return err; } err = eb_add_vma(eb, &current_batch, i, vma); @@ -966,19 +966,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) if (i915_gem_object_is_userptr(vma->obj)) { err = i915_gem_object_userptr_submit_init(vma->obj); - if (err) { - if (i + 1 < eb->buffer_count) { - /* - * Execbuffer code expects last vma entry to be NULL, - * since we already initialized this entry, - * set the next value to NULL or we mess up - * cleanup handling. - */ - eb->vma[i + 1].vma = NULL; - } - + if (err) return err; - } eb->vma[i].flags |= __EXEC_OBJECT_USERPTR_INIT; eb->args->flags |= __EXEC_USERPTR_USED; @@ -986,10 +975,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) } return 0; - -err: - eb->vma[i].vma = NULL; - return err; } static int eb_lock_vmas(struct i915_execbuffer *eb) @@ -3362,6 +3347,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, struct sync_file *out_fence = NULL; int out_fence_fd = -1; int err; + int i; BUILD_BUG_ON(__EXEC_INTERNAL_FLAGS & ~__I915_EXEC_ILLEGAL_FLAGS); BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS & @@ -3375,7 +3361,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, eb.exec = exec; eb.vma = (struct eb_vma *)(exec + args->buffer_count + 1); - eb.vma[0].vma = NULL; + + for (i = 0; i < args->buffer_count; i++) + eb.vma[i].vma = NULL; + eb.batch_pool = NULL; eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS; -- 2.45.2

1 day, 18 hours

4
8
0 0

[REGRESSION] stable-rc/linux-6.1.y: (build) variable 'clidr' is uninitialized when passed as a const pointer a...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- variable 'clidr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] in arch/arm64/kvm/sys_regs.o (arch/arm64/kvm/sys_regs.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:20aa3d9f2fb39bcb7ec7ca6a54be07b6b2668acb - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 87757e18cdafe3f3dd4fc9b9e920e6416e6d00eb Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== arch/arm64/kvm/sys_regs.c:3002:23: error: variable 'clidr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 3002 | get_clidr_el1(NULL, &clidr); /* Ugly... */ | ^~~~~ CC block/partitions/aix.o 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig on (arm64): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm64-allmodconfig-69286db7f5b87… - dashboard: https://d.kernelci.org/build/maestro:69286db7f5b8743b1f65f467 #kernelci issue maestro:20aa3d9f2fb39bcb7ec7ca6a54be07b6b2668acb -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 day, 18 hours

1
0
0 0

[PATCH v3] HID: memory leak in dualshock4_get_calibration_data

by Eslam Khafagy

Function dualshock4_get_calibration_data allocates memory to pointer buf .However, the function may exit prematurely due to transfer_failure in this case it does not handle freeing memory. This patch handles memory deallocation at exit. Reported-by: syzbot+4f5f81e1456a1f645bf8(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/691560c4.a70a0220.3124cb.0019.GAE@google.com/T/ Tested-by: syzbot+4f5f81e1456a1f645bf8(a)syzkaller.appspotmail.com Fixes: 947992c7fa9e0 ("HID: playstation: DS4: Fix calibration workaround for clone devices") Cc: stable(a)vger.kernel.org Signed-off-by: Eslam Khafagy <eslam.medhat1993(a)gmail.com> --- v3: * Address issues reported by checkpatch and re-format commit message for better readability * kfree() is safe so no need to check for NULL pointer v2: https://lore.kernel.org/all/20251116022723.29857-1-eslam.medhat1993@gmail.c… * Adding tag "Cc: stable(a)vger.kernel.org" v1: https://lore.kernel.org/all/20251115022323.1395726-1-eslam.medhat1993@gmail… drivers/hid/hid-playstation.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c index 128aa6abd10b..05a8522ace4f 100644 --- a/drivers/hid/hid-playstation.c +++ b/drivers/hid/hid-playstation.c @@ -1994,9 +1994,6 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4) acc_z_plus = get_unaligned_le16(&buf[31]); acc_z_minus = get_unaligned_le16(&buf[33]); - /* Done parsing the buffer, so let's free it. */ - kfree(buf); - /* * Set gyroscope calibration and normalization parameters. * Data values will be normalized to 1/DS4_GYRO_RES_PER_DEG_S degree/s. @@ -2043,6 +2040,9 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4) ds4->accel_calib_data[2].sens_denom = range_2g; transfer_failed: + /* First free buf if still allocated */ + kfree(buf); + /* * Sanity check gyro calibration data. This is needed to prevent crashes * during report handling of virtual, clone or broken devices not implementing -- 2.43.0

1 day, 18 hours

4
6
0 0

[PATCH v2 6.6] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- v2: Fix duplicate From: header Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 9f64808c7917..a819f198c333 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2255,10 +2255,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_SETUP); rsp->StructureSize = cpu_to_le16(4); -- 2.43.0

1 day, 18 hours

1
0
0 0

[PATCH v2 6.1] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- v2: Fix duplicate From: header Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index d2dca5d2f17c..f72ef3fe4968 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2252,10 +2252,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_NEGOTIATE); rsp->StructureSize = cpu_to_le16(4); -- 2.39.2

1 day, 18 hours

1
0
0 0

Re: [PATCH 6.1] ksmbd: fix use-after-free in session logoff

by SIVARTIWE PROST

Sorry about that! I will send the revised second version shortly

1 day, 18 hours

1
0
0 0

[PATCH] hwmon: (max6697) fix regmap leak on probe failure

by Johan Hovold

The i2c regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 3a2a8cc3fe24 ("hwmon: (max6697) Convert to use regmap") Cc: stable(a)vger.kernel.org # 6.12 Cc: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/hwmon/max6697.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c index 0735a1d2c20f..6926d787b5ad 100644 --- a/drivers/hwmon/max6697.c +++ b/drivers/hwmon/max6697.c @@ -548,7 +548,7 @@ static int max6697_probe(struct i2c_client *client) struct regmap *regmap; int err; - regmap = regmap_init_i2c(client, &max6697_regmap_config); + regmap = devm_regmap_init_i2c(client, &max6697_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); -- 2.51.2

1 day, 19 hours

2
1
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:d414057925e4dea9704ce677eef188319c8610a4 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: b11ac6e8f913ac67f9424a5cdd4158b283c0e3cb Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:69:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 69 | for (int i = 0; i < (1 << order); i++) { | ^ CC arch/arm/mach-imx/mach-vpr200.o mm/mempool.c:71:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 71 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:71:17: note: did you mean 'kmap_to_page'? ./include/linux/highmem.h:67:14: note: 'kmap_to_page' declared here 67 | struct page *kmap_to_page(void *addr); | ^ mm/mempool.c:71:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 71 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:74:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 74 | kunmap_local(addr); | ^ mm/mempool.c:103:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 103 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:105:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 105 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:105:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 105 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:108:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 108 | kunmap_local(addr); | ^ 2 warnings and 6 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286c4df5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286c4df5b8743b1f65f308 #kernelci issue maestro:d414057925e4dea9704ce677eef188319c8610a4 -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 day, 19 hours

1
0
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:edfc0791be4ae7547a2a17054e9cd0317c106f20 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 92a27d160c829ca1d8dd3be92e8e8669620d66d5 Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:68:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 68 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:70:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 70 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:70:17: note: did you mean 'kmap_to_page'? ./include/linux/highmem.h:124:14: note: 'kmap_to_page' declared here 124 | struct page *kmap_to_page(void *addr); | ^ mm/mempool.c:70:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 70 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:73:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 73 | kunmap_local(addr); | ^ mm/mempool.c:101:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 101 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:103:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 103 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:103:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 103 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:106:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 106 | kunmap_local(addr); | ^ CC fs/notify/fanotify/fanotify.o 2 warnings and 6 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286cb5f5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286cb5f5b8743b1f65f372 ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-i386-allmodconfig-69286ceff5b874… - dashboard: https://d.kernelci.org/build/maestro:69286ceff5b8743b1f65f3b6 #kernelci issue maestro:edfc0791be4ae7547a2a17054e9cd0317c106f20 -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 day, 19 hours

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:5387ce1530c340d198d1f318d34f9904675295a1 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 0001989708674740432a288983eddc1fdad1073b Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:68:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] 68 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:101:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] 101 | for (int i = 0; i < (1 << order); i++) { | ^ CC kernel/irq/spurious.o 2 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286d2ef5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286d2ef5b8743b1f65f3ee ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-i386-allmodconfig-69286d6ff5b874… - dashboard: https://d.kernelci.org/build/maestro:69286d6ff5b8743b1f65f41f #kernelci issue maestro:5387ce1530c340d198d1f318d34f9904675295a1 -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 day, 19 hours

1
0
0 0

Optimiza tu reclutamiento con PsicoSmart

by Valeria Pérez

Mejora tus contrataciones con PsicoSmart body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Evalúa talento de forma objetiva y mejora tus contrataciones con PsicoSmart. Hola, , ¿Te ha pasado que un candidato luce perfecto en entrevista, pero en el trabajo no encaja como esperabas? En selección, confiar solo en la percepción puede llevar a decisiones costosas. Por eso quiero presentarte PsicoSmart, una herramienta creada para que los equipos de Recursos Humanos tomen decisiones más objetivas y acertadas. Con PsicoSmart puedes: Aplicar 31 pruebas psicométricas que evalúan liderazgo, honestidad, comunicación e inteligencia. Validar conocimientos técnicos con más de 2,500 exámenes especializados. Supervisar la identidad de quien responde mediante captura fotográfica automática durante la evaluación. Gestionar todo desde una sola plataforma, accesible desde cualquier dispositivo. Si estás buscando mejorar tus contrataciones, podría ser una muy buena opción. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. Saludos, -------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqrwseup">click aquí</a>

1 day, 19 hours

1
0
0 0

[PATCH] soc: samsung: exynos-pmu: fix device leak on regmap lookup

by Johan Hovold

Make sure to drop the reference taken when looking up the PMU device and its regmap. Note that holding a reference to a device does not prevent its regmap from going away so there is no point in keeping the reference. Fixes: 0b7c6075022c ("soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs") Cc: stable(a)vger.kernel.org # 6.9 Cc: Peter Griffin <peter.griffin(a)linaro.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/soc/samsung/exynos-pmu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c index 22c50ca2aa79..ba4de8194a0e 100644 --- a/drivers/soc/samsung/exynos-pmu.c +++ b/drivers/soc/samsung/exynos-pmu.c @@ -346,6 +346,8 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np, if (!dev) return ERR_PTR(-EPROBE_DEFER); + put_device(dev); + return syscon_node_to_regmap(pmu_np); } EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle); -- 2.51.2

1 day, 19 hours

2
4
0 0

[PATCH 6.1] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Nazar Kalashnikov <sivartiwe(a)gmail.com> From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index d2dca5d2f17c..f72ef3fe4968 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2252,10 +2252,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_NEGOTIATE); rsp->StructureSize = cpu_to_le16(4); -- 2.39.2

1 day, 19 hours

2
1
0 0

[PATCH 6.6] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Nazar Kalashnikov <sivartiwe(a)gmail.com> From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 9f64808c7917..a819f198c333 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2255,10 +2255,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_SETUP); rsp->StructureSize = cpu_to_le16(4); -- 2.43.0

1 day, 19 hours

1
0
0 0

[PATCH] Revert "arm64: dts: rockchip: fix audio-supply for Rock Pi 4"

by Quentin Schulz

From: Quentin Schulz <quentin.schulz(a)cherry.de> This reverts commit 8240e87f16d17a9592c9d67857a3dcdbcb98f10d. The original commit claimed that APIO5 IO domain (supplied with audio-supply) is supplied by RK808-D Buck 4 as stated in the schematics. The linked PDF has two non-schematics pages where APIO5 indeed is said to be 1.8V. Reading the actual schematics[1][2][3][4][5][6][7][8], this is actually wrong as APIO5 is supplied VCC_3V0 which is LDO8 from RK808-D and is 3.0V instead of 1.8V from vcca1v8_codec. This fixes the console disappearing in U-Boot, where the Device Tree is imported from the Linux kernel repo, when the IO domain driver is built, as reported by Heinrich[9]. As to why this breaks the console while the serial is not exposed on any of the pins on the bank in the APIO5 domain, that is a well-kept secret by the SoC for now. The issue "fixed" by the original commit will need to be fixed another way. [1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4ap/radxa_rock_4ap_v1600_schem… [2] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4ap/radxa_rock_4ap_v1730_schem… [3] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4bp/radxa_rock_4bp_v1600_schem… [4] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4bp/radxa_rock_4bp_v1730_schem… [5] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/ROCK-4-SE-V1.53-SCH.pdf [6] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4b/ROCK_4B_v1.52_SCH.pdf [7] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/4a/ROCK_4A_V1.52_SCH.pdf [8] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf [9] https://lore.kernel.org/u-boot/e7b7b905-4a6c-4342-b1a5-0ad32a5837cf@gmx.de/ Cc: stable(a)vger.kernel.org Reported-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Note: I do not own any of the Rock Pi 4 variants so I cannot work on fixing the original issue report by Alex. --- arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi index 046dbe3290178..fda7ea87e4efc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi @@ -516,7 +516,7 @@ &i2s2 { }; &io_domains { - audio-supply = <&vcca1v8_codec>; + audio-supply = <&vcc_3v0>; bt656-supply = <&vcc_3v0>; gpio1830-supply = <&vcc_3v0>; sdmmc-supply = <&vcc_sdio>; --- base-commit: 765e56e41a5af2d456ddda6cbd617b9d3295ab4e change-id: 20251127-rock-pi-4-io-domain-apio5-26bc2afa8224 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

1 day, 19 hours

2
1
0 0

[PATCH] Revert "gpio: swnode: don't use the swnode's name as the key for GPIO lookup"

by Charles Keepax

This reverts commit 25decf0469d4c91d90aa2e28d996aed276bfc622. This software node change doesn't actually fix any current issues with the kernel, it is an improvement to the lookup process rather than fixing a live bug. It also causes a couple of regressions with shipping laptops, which relied on the label based lookup. There is a fix for the regressions in mainline, the first 5 patches of [1]. However, those patches are fairly substantial changes and given the patch causing the regression doesn't actually fix a bug it seems better to just revert it in stable. CC: stable(a)vger.kernel.org # 6.12, 6.17 Link: https://lore.kernel.org/linux-sound/20251120-reset-gpios-swnodes-v7-0-a1004… [1] Closes: https://github.com/thesofproject/linux/issues/5599 Closes: https://github.com/thesofproject/linux/issues/5603 Acked-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- I wasn't exactly sure of the proceedure for reverting a patch that was cherry-picked to stable, so apologies if I have made any mistakes here but happy to update if necessary. Thanks, Charles drivers/gpio/gpiolib-swnode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c index e3806db1c0e07..f21dbc28cf2c8 100644 --- a/drivers/gpio/gpiolib-swnode.c +++ b/drivers/gpio/gpiolib-swnode.c @@ -41,7 +41,7 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode) !strcmp(gdev_node->name, GPIOLIB_SWNODE_UNDEFINED_NAME)) return ERR_PTR(-ENOENT); - gdev = gpio_device_find_by_fwnode(fwnode); + gdev = gpio_device_find_by_label(gdev_node->name); return gdev ?: ERR_PTR(-EPROBE_DEFER); } -- 2.47.3

1 day, 20 hours

3
13
0 0

[PATCH v2] mm/kfence: add reboot notifier to disable KFENCE on shutdown

by Breno Leitao

During system shutdown, KFENCE can cause IPI synchronization issues if it remains active through the reboot process. To prevent this, register a reboot notifier that disables KFENCE and cancels any pending timer work early in the shutdown sequence. This is only necessary when CONFIG_KFENCE_STATIC_KEYS is enabled, as this configuration sends IPIs that can interfere with shutdown. Without static keys, no IPIs are generated and KFENCE can safely remain active. The notifier uses maximum priority (INT_MAX) to ensure KFENCE shuts down before other subsystems that might still depend on stable memory allocation behavior. This fixes a late kexec CSD lockup[1] when kfence is trying to IPI a CPU that is busy in a IRQ-disabled context printing characters to the console. Link: https://lore.kernel.org/all/sqwajvt7utnt463tzxgwu2yctyn5m6bjwrslsnupfexeml6… [1] Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Marco Elver <elver(a)google.com> Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") --- Changes in v2: - Adding Fixes: tag and CCing stable (akpm) - Link to v1: https://patch.msgid.link/20251126-kfence-v1-1-5a6e1d7c681c@debian.org --- mm/kfence/core.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/mm/kfence/core.c b/mm/kfence/core.c index 727c20c94ac5..162a026871ab 100644 --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -26,6 +26,7 @@ #include <linux/panic_notifier.h> #include <linux/random.h> #include <linux/rcupdate.h> +#include <linux/reboot.h> #include <linux/sched/clock.h> #include <linux/seq_file.h> #include <linux/slab.h> @@ -820,6 +821,25 @@ static struct notifier_block kfence_check_canary_notifier = { static struct delayed_work kfence_timer; #ifdef CONFIG_KFENCE_STATIC_KEYS +static int kfence_reboot_callback(struct notifier_block *nb, + unsigned long action, void *data) +{ + /* + * Disable kfence to avoid static keys IPI synchronization during + * late shutdown/kexec + */ + WRITE_ONCE(kfence_enabled, false); + /* Cancel any pending timer work */ + cancel_delayed_work_sync(&kfence_timer); + + return NOTIFY_OK; +} + +static struct notifier_block kfence_reboot_notifier = { + .notifier_call = kfence_reboot_callback, + .priority = INT_MAX, /* Run early to stop timers ASAP */ +}; + /* Wait queue to wake up allocation-gate timer task. */ static DECLARE_WAIT_QUEUE_HEAD(allocation_wait); @@ -901,6 +921,10 @@ static void kfence_init_enable(void) if (kfence_check_on_panic) atomic_notifier_chain_register(&panic_notifier_list, &kfence_check_canary_notifier); +#ifdef CONFIG_KFENCE_STATIC_KEYS + register_reboot_notifier(&kfence_reboot_notifier); +#endif + WRITE_ONCE(kfence_enabled, true); queue_delayed_work(system_unbound_wq, &kfence_timer, 0); --- base-commit: ab084f0b8d6d2ee4b1c6a28f39a2a7430bdfa7f0 change-id: 20251126-kfence-42c93f9b3979 Best regards, -- Breno Leitao <leitao(a)debian.org>

1 day, 20 hours

1
0
0 0

[PATCH 6.6.y] smb: client: support kvec iterators in async read path

by Henrique Carvalho

commit 3ee1a1fc39819906f04d6c62c180e760cd3a689d upstream. Add cifs_limit_kvec_subset() and select the appropriate limiter in cifs_send_async_read() to handle kvec iterators in async read path, fixing the EIO bug when running executables in cifs shares mounted with nolease. This patch -- or equivalent patch, does not exist upstream, as the upstream code has suffered considerable API changes. The affected path is currently handled by netfs lib and located under netfs/direct_read.c. Reproducer: $ mount.cifs //server/share /mnt -o nolease $ cat - > /mnt/test.sh <<EOL echo hallo EOL $ chmod +x /mnt/test.sh $ /mnt/test.sh bash: /mnt/test.sh: /bin/bash: Defekter Interpreter: Eingabe-/Ausgabefehler $ rm -f /mnt/test.sh Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Reported-by: Laura Kerner <laura.kerner(a)ichaus.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1245449 Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> --- fs/smb/client/file.c | 46 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c index d883ed75022c..4878c74bae6f 100644 --- a/fs/smb/client/file.c +++ b/fs/smb/client/file.c @@ -3527,6 +3527,42 @@ static size_t cifs_limit_bvec_subset(const struct iov_iter *iter, size_t max_siz return span; } +static size_t cifs_limit_kvec_subset(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs) +{ + const struct kvec *kvecs = iter->kvec; + unsigned int nkv = iter->nr_segs, ix = 0, nsegs = 0; + size_t len, span = 0, n = iter->count; + size_t skip = iter->iov_offset; + + if (WARN_ON(!iov_iter_is_kvec(iter)) || n == 0) + return 0; + + while (n && ix < nkv && skip) { + len = kvecs[ix].iov_len; + if (skip < len) + break; + skip -= len; + n -= len; + ix++; + } + + while (n && ix < nkv) { + len = min3(n, kvecs[ix].iov_len - skip, max_size); + span += len; + max_size -= len; + nsegs++; + ix++; + if (max_size == 0 || nsegs >= max_segs) + break; + skip = 0; + n -= len; + } + + *_nsegs = nsegs; + return span; +} + static int cifs_write_from_iter(loff_t fpos, size_t len, struct iov_iter *from, struct cifsFileInfo *open_file, @@ -4079,6 +4115,13 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, int rc; pid_t pid; struct TCP_Server_Info *server; + size_t (*limit_iov_subset)(const struct iov_iter *iter, size_t max_size, + size_t max_segs, unsigned int *_nsegs); + + if (iov_iter_is_kvec(&ctx->iter)) + limit_iov_subset = cifs_limit_kvec_subset; + else + limit_iov_subset = cifs_limit_bvec_subset; server = cifs_pick_channel(tlink_tcon(open_file->tlink)->ses); @@ -4113,8 +4156,7 @@ cifs_send_async_read(loff_t fpos, size_t len, struct cifsFileInfo *open_file, max_len = min_t(size_t, len, rsize); - cur_len = cifs_limit_bvec_subset(&ctx->iter, max_len, - max_segs, &nsegs); + cur_len = limit_iov_subset(&ctx->iter, max_len, max_segs, &nsegs); cifs_dbg(FYI, "read-to-iter len=%zx/%zx nsegs=%u/%lu/%u\n", cur_len, max_len, nsegs, ctx->iter.nr_segs, max_segs); if (cur_len == 0) { -- 2.47.0

1 day, 20 hours

5
8
0 0

please backport 8c9006283e4b ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"")

by Jani Nikula

Stable team, please backport 8c9006283e4b ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"") from v6.18-rc1 to v6.15+. It's missing the obvious Fixes: 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support TPS4") Thanks, Jani. -- Jani Nikula, Intel

1 day, 21 hours

2
2
0 0

[PATCH] tcpm: allow looking for role_sw device in the main node

by Arnaud Ferraris

When ports are defined in the tcpc main node, fwnode_usb_role_switch_get returns an error, meaning usb_role_switch_get (which would succeed) never gets a chance to run as port->role_sw isn't NULL, causing a regression on devices where this is the case. Fix this by turning the NULL check into IS_ERR_OR_NULL, so usb_role_switch_get can actually run and the device get properly probed. Fixes: 2d8713f807a4 ("tcpm: switch check for role_sw device with fw_node") Cc: stable(a)vger.kernel.org Signed-off-by: Arnaud Ferraris <arnaud.ferraris(a)collabora.com> --- drivers/usb/typec/tcpm/tcpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index cc78770509dbc..37698204d48d2 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -7877,7 +7877,7 @@ struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc) port->partner_desc.identity = &port->partner_ident; port->role_sw = fwnode_usb_role_switch_get(tcpc->fwnode); - if (!port->role_sw) + if (IS_ERR_OR_NULL(port->role_sw)) port->role_sw = usb_role_switch_get(port->dev); if (IS_ERR(port->role_sw)) { err = PTR_ERR(port->role_sw); --- base-commit: 765e56e41a5af2d456ddda6cbd617b9d3295ab4e change-id: 20251127-fix-ppp-power-6d47f3a746f8 Best regards, -- Arnaud Ferraris <arnaud.ferraris(a)collabora.com>

1 day, 21 hours

1
0
0 0

[PATCH] crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode

by Thorsten Blum

The local variable 'i' is initialized with -EINVAL, but the for loop immediately overwrites it and -EINVAL is never returned. If no empty compression mode can be found, the function would return the out-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid array access in add_iaa_compression_mode(). Fix both issues by returning either a valid index or -EINVAL. Cc: stable(a)vger.kernel.org Fixes: b190447e0fa3 ("crypto: iaa - Add compression mode management along with fixed mode") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/crypto/intel/iaa/iaa_crypto_main.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/intel/iaa/iaa_crypto_main.c b/drivers/crypto/intel/iaa/iaa_crypto_main.c index 23f585219fb4..8ee2a55ec449 100644 --- a/drivers/crypto/intel/iaa/iaa_crypto_main.c +++ b/drivers/crypto/intel/iaa/iaa_crypto_main.c @@ -221,15 +221,13 @@ static struct iaa_compression_mode *iaa_compression_modes[IAA_COMP_MODES_MAX]; static int find_empty_iaa_compression_mode(void) { - int i = -EINVAL; + int i; - for (i = 0; i < IAA_COMP_MODES_MAX; i++) { - if (iaa_compression_modes[i]) - continue; - break; - } + for (i = 0; i < IAA_COMP_MODES_MAX; i++) + if (!iaa_compression_modes[i]) + return i; - return i; + return -EINVAL; } static struct iaa_compression_mode *find_iaa_compression_mode(const char *name, int *idx) -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

1 day, 21 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror