From nobody Fri Jun 12 22:35:58 2026 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B67BB48BD3F for ; Tue, 12 May 2026 08:20:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574045; cv=none; b=gP96BbuWLyYPPtmh/FJ+DzYeQJ4Nqo15DjXz/6EBJqgcgp2vDzrv7T88sPiFxSY52+FFOoYEmB08XgYOg9TMxp7DvRsPuo+FXYSUP66kFEGSV1svWzzYhJe0GMx2MdmwYJxkshaXvnQck7C0gtyp6xyJgYwW5rWbsmwO6dEwv1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574045; c=relaxed/simple; bh=Q00x6WZjMklqfpcFl2VKjBA7b7e9J3MZVkUeirnFg7s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KcKw4BlSJ43IMfOrDSODkXPYYhKUOHqQcfTfGBEvXriM+dhiEs0h17SY4YYJ0nBtgryaPuXmcO43aS/grDo/LYD3QzkDMfRJ/h4lueQI20E5Vd3q5UWnn5sgT7Gm1e0t9LB3um9vOkibR1wX2rIw82ks9lpFeqS3bL3q7Memp2Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8DxVejR4gJqaAsJAA--.21755S3; Tue, 12 May 2026 16:20:33 +0800 (CST) Received: from linux.localdomain (unknown [113.200.148.30]) by front1 (Coremail) with SMTP id qMiowJAxGMHO4gJqAwKAAA--.32306S3; Tue, 12 May 2026 16:20:32 +0800 (CST) From: Tiezhu Yang To: Huacai Chen Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v1 1/4] LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration Date: Tue, 12 May 2026 16:20:26 +0800 Message-ID: <20260512082029.2131-2-yangtiezhu@loongson.cn> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20260512082029.2131-1-yangtiezhu@loongson.cn> References: <20260512082029.2131-1-yangtiezhu@loongson.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: qMiowJAxGMHO4gJqAwKAAA--.32306S3 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxWFWftFWfKrWUXFWDuFW5XFc_yoW5AF47pF Zakws0gr4kJa4Sya9I9w4rXrnYkrZ7ArW7GanrKryrtan8tw12vr97KayDXF1kGryktFy3 Zr1qy39rua9rZFXCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUkYb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27w Aqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE 14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCF04k20xvY0x 0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcV C0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF 04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7 CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8r9N3UUUUU== Content-Type: text/plain; charset="utf-8" When probing kernel functions via ftrace, a scheduling event occurring inside the kprobe handler can lead to task migration. If the executing task is migrated to another CPU after setting per-CPU "current_kprobe" but before clearing it, the original CPU is left with a stale state. This stale state causes the original CPU to remain permanently "busy" from the kprobe perspective, as its per-CPU "current_kprobe" is never cleared thereafter. As a result, subsequent kprobes triggered on that CPU are incorrectly treated as nested probes and skipped (increasing nmissed count), leading to functional failures on the affected CPU. Fix this by adding a self-reset mechanism in kprobe_ftrace_handler(). When a kprobe is triggered while the "current_kprobe" is already set, verify if it is a stale state by checking: (1) In task context (not a legitimate interrupt nest). (2) A different kprobe (not a recursive trigger on the same probe). (3) In an active or stepping state. If these conditions are met, it indicates that the previous kprobe execution was scheduled and migrated. Reset the per-CPU state to recover the CPU's kprobe functionality, allowing the current probe to be processed normally. This acts as a defensive mechanism to recover the CPU's kprobe state machine from inconsistent states caused by unexpected task migrations during kprobe execution. Fixes: 09e679c28a4d ("LoongArch: Add kprobes on ftrace support") Reported-by: Hui Li Signed-off-by: Tiezhu Yang --- arch/loongarch/kernel/ftrace_dyn.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/arch/loongarch/kernel/ftrace_dyn.c b/arch/loongarch/kernel/ftr= ace_dyn.c index d5d81d74034c..03d303d67f18 100644 --- a/arch/loongarch/kernel/ftrace_dyn.c +++ b/arch/loongarch/kernel/ftrace_dyn.c @@ -310,6 +310,29 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned = long parent_ip, goto out; =20 kcb =3D get_kprobe_ctlblk(); + + if (kprobe_running()) { + /* + * If a previous kprobe handler was interrupted by a scheduling event + * and the task migrated to another CPU, the "current_kprobe" state + * might be left stale on this CPU. + * + * Reset the stale state here to allow the current probe to proceed + * normally instead of being falsely treated as a nested probe if: + * + * (1) In task context (not a legitimate interrupt nest). + * (2) A different kprobe (not a recursive trigger on the same probe). + * (3) In an active or stepping state. + * + * This acts as a defensive mechanism to recover the CPU's kprobe state + * machine from inconsistent states caused by unexpected task migrations. + */ + if (in_task() && kprobe_running() !=3D p && + (kcb->kprobe_status =3D=3D KPROBE_HIT_ACTIVE || + kcb->kprobe_status =3D=3D KPROBE_HIT_SSDONE)) + reset_current_kprobe(); + } + if (kprobe_running()) { kprobes_inc_nmissed_count(p); } else { --=20 2.42.0 From nobody Fri Jun 12 22:35:58 2026 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CACA0367285 for ; Tue, 12 May 2026 08:20:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574039; cv=none; b=of1T5v4C+N+2MuPQWHUkGbIcPGVwqc20RiA0uJsTQljMLMYF9F6AE9yAGvF+MK6j7dVKzxKBdDADBUFkIzWXLqzN+c+xEveboXshesL8AoopUwRWMBQv+9mXi+CSIHl56rNdDfpKYoq+xXF67HmU/gUBFTLm9lgKucFiQP2Xow4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574039; c=relaxed/simple; bh=5GLlnGoBzMq39eOFhbgKUL8oXZswvWpq9RVaq9yEBsw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tYYYwmlhNSCvJ5sqDhwhPNnnEqp+3E9DtCyPNRo75aUHWP94RH7+vJF+61Bcv/6L8FINEc8kSLf2gjzu2YhnenC2MHFjidEYB7qxXbJuiQUocvcisVjOYk9aMluaqq8mc06lo0oL+blbKxIUAy2d24YvlYcnc9+cRw5fJnzI8Ak= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8Cx4erT4gJqawsJAA--.27815S3; Tue, 12 May 2026 16:20:35 +0800 (CST) Received: from linux.localdomain (unknown [113.200.148.30]) by front1 (Coremail) with SMTP id qMiowJAxGMHO4gJqAwKAAA--.32306S4; Tue, 12 May 2026 16:20:33 +0800 (CST) From: Tiezhu Yang To: Huacai Chen Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v1 2/4] LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions Date: Tue, 12 May 2026 16:20:27 +0800 Message-ID: <20260512082029.2131-3-yangtiezhu@loongson.cn> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20260512082029.2131-1-yangtiezhu@loongson.cn> References: <20260512082029.2131-1-yangtiezhu@loongson.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: qMiowJAxGMHO4gJqAwKAAA--.32306S4 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxArW3Aw17GFW3Xw45Xw47GFX_yoW5Gw1kpF WDCwn0qr4kWF18WFyDJw4UZr1ft3ykuayUWa17A3yrtr4UXryqqFn7KrZ7JF909w4F9F4f Zr1qvFZ5XFyDA3cCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUkFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r126r13M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1DMcIj6I8E87Iv 67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2 Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_JFI_Gr1lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE 42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6x kF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jea0PUUUUU= Content-Type: text/plain; charset="utf-8" On SMP systems, kprobe handlers would occasionally fail to execute on certain CPU cores. The issue is hard to reproduce and typically occurs randomly under high system load. The root cause is a software-side instruction hazard. According to the LoongArch Reference Manual, while the cache coherency is maintained by hardware, software must explicitly use the "IBAR" instruction to ensure the instruction fetch unit (IFU) observes the effects of recent stores. The current arch_arm_kprobe() and arch_disarm_kprobe() only execute the "IBAR" barrier (via flush_insn_slot -> local_flush_icache_range) on the local CPU. This leaves a vulnerable window where remote CPU cores may continue executing stale instructions from their pipelines or prefetch buffers, as they have not executed an "IBAR" since the code modification. Switch to larch_insn_text_copy() to fix this: 1. Synchronization: It uses stop_machine_cpuslocked() to synchronize all online CPUs, ensuring no CPU is executing the target code area during modification. 2. Visibility: By passing cpu_online_mask to stop_machine_cpuslocked(), the callback text_copy_cb() is executed on all online cores. Each CPU core invokes local_flush_icache_range() to execute "IBAR", clearing instruction hazards system-wide and ensuring the "break" instruction is visible to the fetch units of all cores. 3. Robustness: It properly manages memory write permissions (ROX/RW) for the kernel text segment during patching, ensuring compatibility with CONFIG_STRICT_KERNEL_RWX. Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Signed-off-by: Tiezhu Yang --- arch/loongarch/kernel/kprobes.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/loongarch/kernel/kprobes.c b/arch/loongarch/kernel/kprobe= s.c index 8ba391cfabb0..04b5b05715cd 100644 --- a/arch/loongarch/kernel/kprobes.c +++ b/arch/loongarch/kernel/kprobes.c @@ -60,16 +60,18 @@ NOKPROBE_SYMBOL(arch_prepare_kprobe); /* Install breakpoint in text */ void arch_arm_kprobe(struct kprobe *p) { - *p->addr =3D KPROBE_BP_INSN; - flush_insn_slot(p); + u32 insn =3D KPROBE_BP_INSN; + + larch_insn_text_copy(p->addr, &insn, LOONGARCH_INSN_SIZE); } NOKPROBE_SYMBOL(arch_arm_kprobe); =20 /* Remove breakpoint from text */ void arch_disarm_kprobe(struct kprobe *p) { - *p->addr =3D p->opcode; - flush_insn_slot(p); + u32 insn =3D p->opcode; + + larch_insn_text_copy(p->addr, &insn, LOONGARCH_INSN_SIZE); } NOKPROBE_SYMBOL(arch_disarm_kprobe); =20 --=20 2.42.0 From nobody Fri Jun 12 22:35:58 2026 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B182747DD73 for ; Tue, 12 May 2026 08:20:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574049; cv=none; b=qtWXZmdc9ZlajwOa4jCbbzZU+Bs1s/XTLNX3VNiN8oEeb6CUXNX/c+FMBVSbchoVTpybdwNt2K7BLWDoqbmgV+mWkq2dJ9gTaaKZD6tFzwjffwEkFb3xbCixXYBpBSa+f+6Z7Hke1SAk71Ic+FM1HEOe/XT6sDRiC2fHLWvn3TE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574049; c=relaxed/simple; bh=uVDesHUhVeNNwivP/EaIPufI3y6cvuiZLh4SYfalMsk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=obPnA6kzbMDEgNE+4APuMqQv0NYPaLbMAjmBLj+UA61lcqGjbIkOTgxwS+6bYvUjjKtfSPW1ocwpHLIqxEdeTezIK7tw2F9XqCiyJg82aODwwgo2Fd+JmY+1VMQnHAFUSqjxUhPtfbLqYw8sOdihmKs+rSTfoQXGEYY9kQuwhoI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8CxhnjV4gJqbgsJAA--.3071S3; Tue, 12 May 2026 16:20:37 +0800 (CST) Received: from linux.localdomain (unknown [113.200.148.30]) by front1 (Coremail) with SMTP id qMiowJAxGMHO4gJqAwKAAA--.32306S5; Tue, 12 May 2026 16:20:36 +0800 (CST) From: Tiezhu Yang To: Huacai Chen Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v1 3/4] LoongArch: kprobes: Fix single-stepping instruction slot preparation Date: Tue, 12 May 2026 16:20:28 +0800 Message-ID: <20260512082029.2131-4-yangtiezhu@loongson.cn> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20260512082029.2131-1-yangtiezhu@loongson.cn> References: <20260512082029.2131-1-yangtiezhu@loongson.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: qMiowJAxGMHO4gJqAwKAAA--.32306S5 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoW7Zw17ZFy3WF15Kr1Dtr43Arc_yoW8ZrWrpF ZFkw15Xr4rXrW8G3srJw4Dur1Syan5Z3y2gF45Ca4Skw4YqrnIqF1xK3s0vFn8WwsYkF4S v3ZYyF9Yq3W8AacCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUk2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1q6rW5McIj6I8E87Iv 67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2 Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Gr0_Xr1lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE 42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6x kF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUcCD7UUUUU Content-Type: text/plain; charset="utf-8" In arch_prepare_ss_slot(), the original code directly assigns instructions to the buffer using raw memory stores. This approach has two significant drawbacks on LoongArch: 1. Consistency: It skips the necessary instruction barrier synchronization required by the architecture. Without a local barrier, the instruction fetch unit might not observe the newly prepared instructions in the single-step slot, even on the local CPU. 2. Atomicity: Raw memory assignments do not guarantee that the instruction unit sees a complete instruction at all times, which is critical for the integrity of single-step execution. Like RISC-V and ARM64, use larch_insn_patch_text() for slot preparation to ensure the atomic instruction writes and proper local instruction barrier execution. Note that global stop_machine synchronization is not required here because the single-step slot is executed only after a breakpoint exception, which inherently provides a context synchronization event for the CPU to observe the new instructions. Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Signed-off-by: Tiezhu Yang --- arch/loongarch/kernel/kprobes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/loongarch/kernel/kprobes.c b/arch/loongarch/kernel/kprobe= s.c index 04b5b05715cd..8e1b7a87c897 100644 --- a/arch/loongarch/kernel/kprobes.c +++ b/arch/loongarch/kernel/kprobes.c @@ -12,8 +12,8 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk); =20 static void arch_prepare_ss_slot(struct kprobe *p) { - p->ainsn.insn[0] =3D *p->addr; - p->ainsn.insn[1] =3D KPROBE_SSTEPBP_INSN; + larch_insn_patch_text(p->ainsn.insn, *p->addr); + larch_insn_patch_text(p->ainsn.insn + 1, KPROBE_SSTEPBP_INSN); p->ainsn.restore =3D (unsigned long)p->addr + LOONGARCH_INSN_SIZE; } NOKPROBE_SYMBOL(arch_prepare_ss_slot); --=20 2.42.0 From nobody Fri Jun 12 22:35:58 2026 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BF00A36F8E9 for ; Tue, 12 May 2026 08:20:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574057; cv=none; b=MwiDM8t7uUdYU1y1vhIy6osQUnEqY1NBgLhkBZYhWdXYSEu8J56/Uzsdgqci8pmfnfE5cYOJZYk0pXCl4hyhZtM7Gk8PS8ST3sEPzqUCXH/z3FmLCqUTKfYdK/UGH6UwZAf9GDzqbQBtdForiwybkBkd4P7ZA315YrzSo/xfLMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778574057; c=relaxed/simple; bh=m0pjb+lFxwODsmHUtZbhrvJuChOfG2RNq0/7PzBItJ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dv4aJN04bofaKekCaPDfTcTrhY5IegAHgotv2MSxGgYjR+hw95kIujBDx67eUE0t2WuEq86pocrZZItxxBmhkPO59NtC/DdDxzfwJv47o93tYpWbTb01hCHdTM9TxbOvl2NhBatcOjH8bP4cV2zOswrh7WPOR59qDMd0LVmoiuw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8CxncDe4gJqeAsJAA--.4033S3; Tue, 12 May 2026 16:20:46 +0800 (CST) Received: from linux.localdomain (unknown [113.200.148.30]) by front1 (Coremail) with SMTP id qMiowJAxGMHO4gJqAwKAAA--.32306S6; Tue, 12 May 2026 16:20:37 +0800 (CST) From: Tiezhu Yang To: Huacai Chen Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v1 4/4] LoongArch: kprobes: Fix handling of fatal unrecoverable recursions Date: Tue, 12 May 2026 16:20:29 +0800 Message-ID: <20260512082029.2131-5-yangtiezhu@loongson.cn> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20260512082029.2131-1-yangtiezhu@loongson.cn> References: <20260512082029.2131-1-yangtiezhu@loongson.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: qMiowJAxGMHO4gJqAwKAAA--.32306S6 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxWr1kGrW3Xr1xWrWkuF48AFc_yoW5WF1DpF WkAws0qrs5Ga18Za4qyw4UZrWFka1DArW7Gw4rAa4Yy3W5GF47tryxKrWUtFyrCr95Kw4I vFnYkrW0gFW7ArXCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUk2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1q6rW5McIj6I8E87Iv 67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2 Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Gr0_Xr1lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE 42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6x kF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUcHUqUUUUU Content-Type: text/plain; charset="utf-8" KPROBE_HIT_SS and KPROBE_REENTER are two types of fatal recursions that can not be safely recovered in kprobes. KPROBE_HIT_SS means that a kprobe is hit during single-stepping. At this point, the architecture-specific single-step context is already active. Nested single-stepping would corrupt the state, as the kprobe control block (kcb) and hardware registers cannot safely store multiple levels of stepping state. KPROBE_REENTER means that a third-level recursion occurs when a probe is hit while the system is already handling a nested probe (second-level). The kcb only provides a single slot (prev_kprobe) to backup the state. When a third probe is hit, there is no more space to save the state without corrupting the first-level backup. Kprobes work by replacing instructions with breakpoints. In order to execute the original instruction and continue, it must be moved to a temporary "single-step" slot. Since there is no backup space left to set up this slot safely, the CPU would be forced to return to the same original breakpoint address, triggering an endless loop. Currently, the code only prints a warning and returns. This leads to an infinite re-entry loop as the CPU repeatedly hits the same trap and a "stuck" CPU core because preemption was disabled at the start of the handler and never re-enabled in this early return path. Fix the logic by: 1. Merging KPROBE_HIT_SS and KPROBE_REENTER cases, as both represent fatal recursions that cannot be safely recovered. 2. Balancing the preemption count with preempt_enable_no_resched() to maintain preemption balance before the system halts. 3. Replacing WARN_ON_ONCE() with BUG() to terminate the system. This aligns LoongArch with other architectures (x86, arm64, riscv) and prevents stack overflow while providing diagnostic information. Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Signed-off-by: Tiezhu Yang --- arch/loongarch/kernel/kprobes.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/loongarch/kernel/kprobes.c b/arch/loongarch/kernel/kprobe= s.c index 8e1b7a87c897..e6395a9dbaec 100644 --- a/arch/loongarch/kernel/kprobes.c +++ b/arch/loongarch/kernel/kprobes.c @@ -186,16 +186,17 @@ static bool reenter_kprobe(struct kprobe *p, struct p= t_regs *regs, struct kprobe_ctlblk *kcb) { switch (kcb->kprobe_status) { - case KPROBE_HIT_SS: case KPROBE_HIT_SSDONE: case KPROBE_HIT_ACTIVE: kprobes_inc_nmissed_count(p); setup_singlestep(p, regs, kcb, 1); break; + case KPROBE_HIT_SS: case KPROBE_REENTER: + preempt_enable_no_resched(); pr_warn("Failed to recover from reentered kprobes.\n"); dump_kprobe(p); - WARN_ON_ONCE(1); + BUG(); break; default: WARN_ON(1); --=20 2.42.0