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 36C31249E5 for ; Fri, 5 Jun 2026 00:33:15 +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=1780619596; cv=none; b=AP+WI/Vmla70W6+wkOVXE2iYEtgWTS3iK3FK2x0iV7YXKORNX50WJBor+xFaUzBCeS+zk1/2CoOZQ6RIA9pCwrXUfUb58zUvyP9R1QDW9VlqbeJ514RAPxo1M6a2vTpy+7WSPK1ag2SCT/ueBee/VQXOSaEkSLSJy5I7qb5XoIc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780619596; c=relaxed/simple; bh=rZ+Ds1JD3VyvuMGUEsXoxAO93Goe7hr74okGjTd8DU4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=mpcqbpKKN5gbHELdpATpa6DP/vNSyh5BuIrQZTLhDLWraEVwiB28d44YWH7vPapWJ83qqeWLencXlY7cAG6qPKUyn7V38ytMY8HlqXBV8S/TGGMBtwuLJYGJC+PFc7+RVSKKia9VMO2nxHZpQc7CurjFu+/VY7CyFOLPdzLWsS4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DBpud2Pm; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DBpud2Pm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 838FA1F00898; Fri, 5 Jun 2026 00:33:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780619595; bh=6+s6KKycAc/Fz4BlySEdjg1gmHZM9RQ7tU/fSP165RI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DBpud2Pmz1y58gOVXeNF2uN3wXyqmI5XJQg+hfI9/Psi1QoVBdDDN0VnS/8EhUbez yyorZVIPp/ITDIumR0qvVQoSR4EnXy634/iNf4RyC3ThOCRg4Fanvio2xZVyRtCBCJ iZG+rTfqXt9DcqFufOIEHIn34kkJliQ2k5TS5sxsfs8pMGLooDjEfNqv7kEDlqyriH ZTKHXg7hMn5ezOXwbVW0Q0aesUfsSizeVYHTCECZTzFei+fPj88sHnZ2z8MhFJKX+y ujNA+RbhuxTnhQ3ADmkluOrL+jnsM10towz2olLa+ssXUlcN/Is53MTWedpzQ99/B/ hibSVTzsg+QjA== Date: Thu, 4 Jun 2026 18:33:13 -0600 (MDT) From: Paul Walmsley To: Rui Qi cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/2] riscv: stacktrace: Use %pB for backtrace display In-Reply-To: <20260603115329.791603-3-qirui.001@bytedance.com> Message-ID: <4197ee54-6c69-cb72-5966-c60ba321a6fa@kernel.org> References: <20260603115329.791603-1-qirui.001@bytedance.com> <20260603115329.791603-3-qirui.001@bytedance.com> 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=US-ASCII 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