From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99CCB37E2E5; Thu, 20 Aug 2026 15:08:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787238520; cv=none; b=BQly90F55mu9iENxurP6dQpOUr1GYrMYGHSscNpyoZJwL/TUakW5dykIq42VVo/WjYUFCgKtZTA5yLh/CSBGNzOyNzIMG12LovTw0/2qkS96J4nF9LtGWpkhUK/wkW0wFS26fUFqTXvuF8bYmttxAY9vaKggWUZf3dmMI7OQqUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787238520; c=relaxed/simple; bh=FsziV17RTMFCWrYbZdz6Rny8J+lfL9L9ic95LgTVzjs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gBCZoNfOH0Tpr4rhmR/DKkvTCzlN3bGur1cQz2XknVXo3/kAvvcSWbiHuFL0KQEg6jQde4SiPKAAkNBkhuboDzZLEnBIYb4g2FkzLmaAIipaSmQ64ApgGpFKzDCVc9xFuQVF4u/xHmJXqFbP++X8coRhcOZure/V+XaQMoTy97s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=HK257NqZ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="HK257NqZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD40B1F000E9; Thu, 20 Aug 2026 15:08:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1787238519; bh=BoIwAYmo3faMmnm3OyP13MBz6K2w7R76XSxaS8Ea+mY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HK257NqZwcUMarywDwzUXwMJGlrpjXhU6vSl+6AEpzQWdzZgjeob+SQiucx0Yfgjg mTc4DyaMLwfRVpwBcKqL/9czT1/vrvoDXZsJWWlD3r6TiVwMOFpYia1KPA+Is84Sg4 OLzot8H7WhbQDeeRFlFcV2m4iS31JJsWW8gBvuQY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Pu Lehui , Paul Walmsley , Sasha Levin Subject: [PATCH 7.1 175/228] riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions Date: Thu, 20 Aug 2026 16:55:17 +0200 Message-ID: <20260820145250.008478169@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260820145244.450574346@linuxfoundation.org> References: <20260820145244.450574346@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Pu Lehui [ Upstream commit 2820d227ad4ee70805d693d698437cc3e88d6c3d ] We are frequently hitting the following splat during the riscv bpf selftests: 00000000026dc75a: expected (7c3ff297) but got (00100073) ------------[ ftrace bug ]------------ ftrace failed to modify [] bpf_kfunc_common_test+0x4/0x20 [bpf_testmod] actual: e7:82:c2:ce Updating ftrace call site to call a different ftrace function ftrace record flags: 80100002 (2) expected tramp: ffffffff80043904 ------------[ cut here ]------------ WARNING: kernel/trace/ftrace.c:2278 at ftrace_bug+0x46e/0x4b0, CPU#1: test_progs/98 ... [] ftrace_bug+0x46e/0x4b0 [] ftrace_replace_code+0x16e/0x170 [] ftrace_modify_all_code+0x12e/0x1b8 [] arch_ftrace_update_code+0x14/0x28 [] ftrace_startup+0x14c/0x2a0 [] ftrace_startup_subops+0x584/0x1050 [] register_ftrace_graph+0x4e6/0x1018 [] register_fprobe_ips+0xc66/0x12f8 [] bpf_kprobe_multi_link_attach+0x5d8/0xe68 [] __sys_bpf+0x3d5a/0x47f0 [] __riscv_sys_bpf+0xae/0x168 [] syscall_handler+0x60/0x100 [] do_trap_ecall_u+0x174/0x208 [] handle_exception+0x16c/0x178 After debugging, it can be triggered by similar commands below: ``` echo do_nanosleep > set_ftrace_filter echo function > current_tracer echo 'p do_nanosleep' > kprobe_events echo 1 > events/kprobes/enable echo 'f do_nanosleep' > dynamic_events echo 1 > events/fprobes/enable ``` The reason is that attaching a kprobe to an ftrace-traced function entry replaces its initial auipc insn with ebreak. When ftrace_modify_call later runs, it expects auipc insn, so verification fails and triggers ftrace_bug. The expected auipc logic remains conceptually unchanged, and kprobe single-stepping ensures normal execution. Therefore, if the first insn is ebreak, bypassing the check to continue patching the jalr insn is safe and avoids ftrace failures. Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching") Signed-off-by: Pu Lehui Link: https://patch.msgid.link/20260802094929.3978390-1-pulehui@huaweicloud.com [pjw@kernel.org: fixed reproducer in commit message] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin --- arch/riscv/kernel/ftrace.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c index b430edfb83f4c..be8b685144174 100644 --- a/arch/riscv/kernel/ftrace.c +++ b/arch/riscv/kernel/ftrace.c @@ -12,6 +12,7 @@ #include #include #include +#include #ifdef CONFIG_DYNAMIC_FTRACE void ftrace_arch_code_modify_prepare(void) @@ -63,7 +64,9 @@ static int __ftrace_modify_call(unsigned long source, unsigned long target, bool if (copy_from_kernel_nofault(replaced, (void *)source, 2 * MCOUNT_INSN_SIZE)) return -EFAULT; - if (replaced[0] != call[0]) { + /* Bypass the check if the auipc insn is a kprobe breakpoint */ + if (replaced[0] != call[0] && + !(riscv_insn_is_ebreak(replaced[0]) || riscv_insn_is_c_ebreak(replaced[0]))) { pr_err("%p: expected (%08x) but got (%08x)\n", (void *)source, call[0], replaced[0]); return -EINVAL; -- 2.53.0