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 10D4F3314B9 for ; Thu, 4 Jun 2026 23:41:11 +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=1780616472; cv=none; b=Y7IdeG0E5tsU7CqC8djIcNV5za+qF+fQuO5Cf6/dhb1xFiY9lhHHG/0fhBcZUV/4Q6V1gw9/kicpuGhJcLRjMe3IZgab0VWLwryAJvEKTPoCr69fzCfib8XfugDpZKSaTJCt9/p41CageAMGCk8cdtdK8RIlNDAeN4LJ1cn9cMU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780616472; c=relaxed/simple; bh=U6cErZ4vAnPUE6yCaPD0+xtPyWtfMsSaUk+mp4jOTlI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=CKqwU2EHquk6TQq6FuMs4twppBvDKYXU40pTp7w+OlSiBhrvLzZU7jvCzjjHQFYynXcBKfW0Y4/R6S2myENDhkg5ZVoQyhnhyUB5eQ4yeU1FX1Oj03pdy1fHhnUhU0muYzmXXL+Zv5/ar2AMFq8AG8mtPfP9sDtcrxTLetF3F9k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XObhX4ep; 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="XObhX4ep" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 461CC1F00893; Thu, 4 Jun 2026 23:41:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780616471; bh=0QHV2vYtmnptSefCqHx+b7ZWaXLYqZiwKrxHa/B0vT4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XObhX4epIbXAvf4gJLVS2l7go87WDWpatv71tnGat+lNo1Cl4lOdhKzQI/3Tyxu9U VfhuMd3xkHIWgOEUUEgX7o3s0uTc8aPUIPTovR9xS+bLvt75MWHjaXRferZhBkaII6 U6mhXvJucoNgYf8Whg+1D+sTDTgSFmQACJTBc8d+D6rZHqxknMkd1gHJ+KV0BsX0Sh EdvfHJXRdp5Yi7Fl3Y0rJXU5BV/+zxHS99E55xeJHN5PMOBwJeFZ/uvzQI8X5XhbCP HUSzKRs0X93xryrvAPMbgLe/3V7WhtRQM9FGgxZF2Ej6JD/ZA8mbuiBSC04wTRbm4R jxZt2BEUUyt+A== Date: Thu, 4 Jun 2026 17:41:10 -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 1/2] riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe In-Reply-To: <20260603115329.791603-2-qirui.001@bytedance.com> Message-ID: References: <20260603115329.791603-1-qirui.001@bytedance.com> <20260603115329.791603-2-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: > 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 = > frame->ra - 0x4" with ftrace_graph_ret_addr(), and the commit > message explicitly noted that "the original calculation, pc = > 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. Thanks for the very clear commit message and for the fix. Queued for v7.1-rc. - Paul