From nobody Mon Jun 8 07:26:14 2026 Received: from va-1-115.ptr.blmpb.com (va-1-115.ptr.blmpb.com [209.127.230.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A657F46AF03 for ; Wed, 3 Jun 2026 11:53:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.115 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780487639; cv=none; b=C/Vl0D70Tt+UuzjhN/u0L6PmbngSUVbQGhZ9BL1W8nRgop9XnUPCeGmcTzFbwnOcq/QdEWVmMaWn/kh+8mCTXcCbB56lzTzg2uiRQDN74KtnJduzSevW73dlBOLd+20Kzwsl0b5MijaOYDF7Vit/5Jtr6s07WH97BsKLyp1vYWQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780487639; c=relaxed/simple; bh=XOvsd6h+jIZ2iJRSjD46U5o0MdzI7/ozxfiQMlpEXII=; h=Date:Message-Id:References:Cc:Subject:Content-Type:To:In-Reply-To: From:Mime-Version; b=eo7rXUv4bPsmx7wsQ2vfiawQkBCsLPVM9FF8gbf1L2qp35GmgQg10bEnUKdHe7jPrSM7Xc1tFUJB3uikc94Nsqp4SLNJKsAxVxUmGddYaqG4+R8Gwd7u7e+5AxrlHczmdOg8QaRe/O1fBMSschLL+BlWpYFf/IjdQ0D7g64HMgU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=JWTvIoSw; arc=none smtp.client-ip=209.127.230.115 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="JWTvIoSw" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780487633; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=joVqT0sbeZstg7foR7ZySXhhdOS5ZDwWEcSwH6D6Mjs=; b=JWTvIoSwatvWvvJ0Gv5673oKRWhi97sv3z8syThRWq+pH8V+HdHrn6IRsn0v+Vmfc0VPI4 mcT0slUGTsTQUWYdHQh8Nhwpa9KqJug62hHVwPtNp9XXLi+s/O0M10tRF7jwHUiWE+FjNU qXRTaxFVsNcye+kFuc9mWMLTV1SYwntkHFgLwsPbVTbpBrAuNPMOIZlVWo5pjTpgcsMbha xJUKGp3VDd5ZiqW1ykZKk/zsrOGOsGnVVejm2vQB+lFBha6KxXTWkKc5cKRGlUqY9QgWCq n1Cz2TrZKWKRlI8H3dfY/cJJzdij0KxLt8e92AuKNjlgyd3CEvfuihDqEYJkww== Date: Wed, 3 Jun 2026 19:53:28 +0800 Message-Id: <20260603115329.791603-2-qirui.001@bytedance.com> References: <20260603115329.791603-1-qirui.001@bytedance.com> Cc: "Alexandre Ghiti" , , , "Rui Qi" Subject: [PATCH v1 1/2] riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe X-Original-From: Rui Qi X-Mailer: git-send-email 2.20.1 To: "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" Content-Transfer-Encoding: quoted-printable In-Reply-To: <20260603115329.791603-1-qirui.001@bytedance.com> X-Lms-Return-Path: From: "Rui Qi" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" In the non-frame-pointer version of walk_stackframe, each value read from the stack is treated as a potential return address and has 0x4 subtracted before being used as the program counter. This was intended to convert the return address (the instruction after a call) back to the call site, but it is incorrect: 1. RISC-V has variable-length instructions due to the RVC (compressed instruction) extension. A call instruction can be either 4 bytes (regular) or 2 bytes (compressed, e.g. c.jal). Subtracting a fixed 0x4 assumes all call instructions are 4 bytes, which is wrong for compressed instructions. 2. Stack traces conventionally report return addresses, not call sites. Other architectures (ARM64, x86, ARM) do not subtract instruction size from return addresses in their stack unwinding code. 3. The frame-pointer version of walk_stackframe already dropped the -0x4 offset. Commit b785ec129bd9 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") replaced "pc =3D frame->ra - 0x4" with ftrace_graph_ret_addr(), and the commit message explicitly noted that "the original calculation, pc =3D frame->ra - 4, is buggy when the instruction at the return address happened to be a compressed inst." The non-FP version was simply overlooked. Remove the bogus -0x4 offset to match the FP version and the conventions used by other architectures. Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly") Signed-off-by: Rui Qi --- arch/riscv/kernel/stacktrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c index 2692d3a06afa..c7555447149b 100644 --- a/arch/riscv/kernel/stacktrace.c +++ b/arch/riscv/kernel/stacktrace.c @@ -129,7 +129,7 @@ void notrace walk_stackframe(struct task_struct *task, while (!kstack_end(ksp)) { if (__kernel_text_address(pc) && unlikely(!fn(arg, pc))) break; - pc =3D READ_ONCE_NOCHECK(*ksp++) - 0x4; + pc =3D READ_ONCE_NOCHECK(*ksp++); } } =20 --=20 2.20.1 From nobody Mon Jun 8 07:26:14 2026 Received: from va-1-114.ptr.blmpb.com (va-1-114.ptr.blmpb.com [209.127.230.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1350147799F for ; Wed, 3 Jun 2026 11:54:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.114 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780487648; cv=none; b=THvwXeyE997xEYZlwf0HFcv44L9Uoq1ZfzvH5PH/mWVb4Y9B9cSlF2jUVHpHu6IHck8LcK27eYLqoFegSvYOvGE32sWOKwU8G+bQSAg3sAaw0U65g5UuyhA5f8/Q4auxQ0dIHrkLsoZR8W1fUj1YS78L/MHxXfjl0UYB0V0SLkE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780487648; c=relaxed/simple; bh=xT+k8HJ+Ko7c350z4fweTH86UeGQZmagQ3kFYQERU4M=; h=Mime-Version:References:In-Reply-To:To:Cc:Date:From:Subject: Content-Type:Message-Id; b=thnIhvQx9I3cPWZz4Msra/GduHwD018gCH2QeCN8lkgDJa01WH1PieH9LjwTkVM/LaPL1DfxWXhwt+nJbyzx8BvaXcl9f1ihHd58Atnm2bbrAOS8wPHJCrkZ5UGFc2ZITHWgaUNY+eZQ4yYDnlCMhg4BboAhDm8E78R/oFQS5zY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=mF5qV1B6; arc=none smtp.client-ip=209.127.230.114 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="mF5qV1B6" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780487642; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=BP6MKTedQDfeKoLFnuCL3wxv2kHIK4oguFbN4oqvk/8=; b=mF5qV1B63u0J5WypTntOfCE60mNqAj4uJ38fTE35DqrjL3fHJkcM1fwFgJdKKrlRz9thwt UI3xyJ2iQBP/3ftTHeL9+hDMcTBvTpEAhBH85papDBwimOsV4L6VqpKr4Fy0kngbp5o20n g0wcKXnYxMj+7a1cSa7jTL+giMDPbgHEVDC35uTh9OyuwG8oAmKPFha9evHnO64T/qXG5n S/bRPGaULqvwokG5/nKdB7SbFYlaSpwNfjVntevEcFQts/6ZACotnEhjYadOe8eBLq7MKw tpynu4M33T21gB9XUgO0HicIf12mMQn0TFGJumTE3xdGUuZ2JKuu7miRAWExVg== 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-Mailer: git-send-email 2.20.1 References: <20260603115329.791603-1-qirui.001@bytedance.com> In-Reply-To: <20260603115329.791603-1-qirui.001@bytedance.com> To: "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" Cc: "Alexandre Ghiti" , , , "Rui Qi" Date: Wed, 3 Jun 2026 19:53:29 +0800 From: "Rui Qi" Subject: [PATCH v1 2/2] riscv: stacktrace: Use %pB for backtrace display Message-Id: <20260603115329.791603-3-qirui.001@bytedance.com> X-Original-From: Rui Qi X-Lms-Return-Path: Content-Type: text/plain; charset="utf-8" The print_trace_address callback uses print_ip_sym which formats addresses with %pS. This does not adjust the address before symbol lookup, so when a noreturn function (e.g. panic, do_exit) is the last call in a function, the saved return address can point to the start of the next function, and kallsyms resolves it to the wrong symbol. The kernel provides %pB (sprint_backtrace) specifically for this purpose: it subtracts 1 from the address before symbol lookup, which is sufficient to fall back into the calling function range. x86 uses %pB in its printk_stack_address for the same reason. Replace print_ip_sym with a direct printk using %pB, matching the pattern used by x86. Signed-off-by: Rui Qi --- arch/riscv/kernel/stacktrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c index c7555447149b..f4eb65bf53ef 100644 --- a/arch/riscv/kernel/stacktrace.c +++ b/arch/riscv/kernel/stacktrace.c @@ -139,7 +139,7 @@ static bool print_trace_address(void *arg, unsigned lon= g pc) { const char *loglvl =3D arg; =20 - print_ip_sym(loglvl, pc); + printk("%s[<%px>] %pB\n", loglvl, (void *)pc, (void *)pc); return true; } =20 --=20 2.20.1