From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-111.ptr.blmpb.com (va-1-111.ptr.blmpb.com [209.127.230.111]) (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 17434494A15 for ; Fri, 5 Jun 2026 08:13:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780647189; cv=none; b=Qmh/Mto1znNWbzC2UboerrmniTz/kYSfm9mn971qmiF0pgKaKLBwDVXgMm8SnjhIyU3DYp3VCoineK9hKXPhOANeerYf1csX4jlDb1g8SxdNnoWB0C+uuzil12frMni6rLfr/tMVPsgX93PTjBhWdx90aOeD0NMnaWk56ij1y/U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780647189; c=relaxed/simple; bh=Rn3MGdtvDYpmrDDys4n4LUU2rAPs7Dhvg4bcUyvgs8g=; h=Date:From:Subject:Mime-Version:In-Reply-To:Content-Type:To: Message-Id:References:Cc; b=vDTqRmF2P6rx5iGqqq8cB/IPlBMHf0ivrR7OHl4358ShUXOCfL3QAd6v9/7LsGf6+JnjhlNLFu7HatH120r2s+6qo0K+N1izW5U6PTl6yr4iqfjOwaIxqJRH/79rDeG0hssBdQ49853MOvsbfBfN22kP5tGwWpp99rA+1xKe+9A= 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=OsbFaj1H; arc=none smtp.client-ip=209.127.230.111 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="OsbFaj1H" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780647180; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=xYTHDl2AajBOqR+4sy4po6w/RbkMf3J7YI6AkJg4pU8=; b=OsbFaj1Htl7RtRr1AhYVwO72Q7rmq/39SAMI+ZIK5YspR6iHkMH6sJsuSl++O+oDayYH1W QS3N7evby93Qe4Ytmz+5vqvgZiNlGKH508NcliP7WH2TCZKChOdYRMy+LKeL4n4vGAhg/V X9PEG8TgogqP7BC/A4GnrSzVKgavYWnm2BIBXSPGCWHqeHUBjzywvEBND2pux2qnt1Uv/M GZXKihJKFEQDNGDofkxcxWIdRFNA2W6EosS9Sc0AUb7tNUfBX6uyCP5VP9GIAtFi+U/23u 3NKBwuenAWFwt6LlamqciT2tFfag0U6LMcaoVqB8nJ4CB6djMUCzVJycCJNFLw== Date: Fri, 5 Jun 2026 16:12:42 +0800 User-Agent: Mozilla Thunderbird X-Lms-Return-Path: From: "Rui Qi" Subject: Re: [PATCH v1 2/2] riscv: stacktrace: Use %pB for backtrace display Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Original-From: Rui Qi In-Reply-To: <4197ee54-6c69-cb72-5966-c60ba321a6fa@kernel.org> Content-Type: text/plain; charset=UTF-8 To: "Paul Walmsley" Message-Id: <226fe0d0-3d05-4c6b-95fb-a058da2d4169@bytedance.com> References: <20260603115329.791603-1-qirui.001@bytedance.com> <20260603115329.791603-3-qirui.001@bytedance.com> <4197ee54-6c69-cb72-5966-c60ba321a6fa@kernel.org> Cc: "Palmer Dabbelt" , "Albert Ou" , "Alexandre Ghiti" , , Content-Transfer-Encoding: 7bit On 6/5/26 8:33 AM, Paul Walmsley wrote: > On Wed, 3 Jun 2026, Rui Qi wrote: > >> 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 > > The Sashiko review mentions that the x86 backtrace code uses %pS for exact > instruction pointers coming from registers (show_regs_if_on_stack()), vs. > %pB for return addresses on the stack (printk_stack_address()): > > https://sashiko.dev/#/patchset/20260603115329.791603-1-qirui.001%40bytedance.com > > Do we need to incorporate similar logic? > > > - Paul Hi Paul, Yes, you are right. The Sashiko review raises a valid point that I should have addressed in the original patch. %pB subtracts 1 from the address before symbol lookup, which is correct for return addresses but wrong for exact instruction pointers: if the exact IP happens to be at offset 0 of a function, subtracting 1 causes kallsyms to resolve it to the preceding function. In walk_stackframe(), two kinds of addresses are passed to the callback: Exact instruction pointers: instruction_pointer(regs) and the epc from exception frames found during unwinding (when the return address points into handle_exception..ret_from_exception_end). These should use %pS. Return addresses: frame->ra, regs->ra, task->thread.ra. These should use %pB. I have updated the patch to add an 'is_ra' parameter to the walk_stackframe callback, indicating whether the address is a return address. print_trace_address() then uses %pB when is_ra is true and %pS when is_ra is false, matching the x86 approach. For the generic arch_stack_walk() path, since stack_trace_consume_fn has a fixed 2-parameter signature, a thin wrapper (stack_walk_wrapper) adapts between the two callback types, discarding the is_ra flag since the generic stack trace infrastructure only records raw addresses. One known limitation: the non-FP version of walk_stackframe() scans the stack blindly and cannot distinguish pt_regs->epc values from return addresses, so all stack-scanned values are treated as return addresses (is_ra = true). This means epc values from pt_regs encountered during the scan may still use %pB incorrectly. This is an inherent limitation of the non-FP unwinder and not introduced by this change; the FP version handles the epc case correctly. The updated patch will be in v2.