From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-113.ptr.blmpb.com (va-1-113.ptr.blmpb.com [209.127.230.113]) (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 67D405474F for ; Mon, 22 Jun 2026 02:54:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782096894; cv=none; b=fOLc3vZFNGzia6kly+Gt2/omTkBDDeTCZXnY8A+8UkvnvT0AhLR79Tr8+vgn1gKMTunAu2dCB3/y5hsJKgM4Gz2G0nxijDxG9DxrwTgvsi8a846ED8HAxMkWYMN5Ey4uYx2nHIrLCRUmz7cG0idbFyuwg+DFZVi1ZzhrYvZUK9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782096894; c=relaxed/simple; bh=D2Fobvumlwf/2MA6sXRWWufR/wSs21yx59oJDNMMi4Q=; h=Message-Id:To:Mime-Version:Subject:Date:Content-Type:References: In-Reply-To:From:Cc; b=FywGlGiemqHOvC1KISpWkfkQHJSIl8rcdr4D6ydWP04qX5C32MMJLcCMDha2BNotRYtZqk6atQ7MtCkbY9QX231tAkagUw0QtrePHhno9gid6Khc5JtW0HiuSPrGZKowKWtghqLEcrTmfB6sU2fskTpC6qufk8/LaG9/P9x8nEA= 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=qqxW/40Q; arc=none smtp.client-ip=209.127.230.113 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="qqxW/40Q" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1782096880; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=MVFhmxXtrbmG+CWiqbe7ir8ZqzPje6y+FF2v778FjIw=; b=qqxW/40QBaj1qPvisEQmOMt+Oz5z9cdyOljS+b+bIW/0E6rdWdOREcg8vKpatUVJUREOKb FbRLjsD/OwL3dlS/c7Fasqgvz4qZpQlQCr8+xDCAXwdo+CWvj6U1al/AG+6XCYUrYhkKro 3sJIiROenFZSoDwt2mrknSMlK8Irmv/tSNRULn6+jhEcrLQSii8B3v3UYWxKVkQQwaFNFz lCMvuUhZVdPM+hUxtytfhbe+y6ocJj+UI/Q3Ghzm51TnDojYHcTEAurI7kRc4YYpINI1U4 H4ZfJun+4g51TEs5tZ+Q8JASkCY/cdpjAMTsVJ0ETAFqT67f/dGUstM/pnRG2Q== Message-Id: User-Agent: Mozilla Thunderbird To: , , , , "Conor Dooley" X-Original-From: Rui Qi Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Subject: Re: [PATCH] riscv: fix frame pointer in call_on_irq_stack for RV32 Date: Mon, 22 Jun 2026 10:54:25 +0800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <20260603035305.564823-1-qirui.001@bytedance.com> In-Reply-To: <20260603035305.564823-1-qirui.001@bytedance.com> From: "Rui Qi" X-Lms-Return-Path: Cc: , Hi Palmer, Paul, Albert, Alexandre, Gentle ping on this patch. It has been posted for over two weeks now and I would appreciate any feedback. This fixes a frame pointer bug in call_on_irq_stack on RV32 where the unwinder reads from the alignment padding instead of the actual saved fp/ra, causing broken stack traces on 32-bit RISC-V. Please let me know if there are any concerns or if further changes are needed. +Cc: Conor Dooley -- adding RISC-V subsystem reviewer. On 6/3/26 11:53 AM, Rui Qi wrote: > The frame pointer (s0/fp) in call_on_irq_stack is set using > STACKFRAME_SIZE_ON_STACK, which equals ALIGN(sizeof(struct stackframe), > STACK_ALIGN). On RV64, sizeof(struct stackframe) is 16 and the aligned > size is also 16, so there is no difference. However, on RV32, > sizeof(struct stackframe) is 8 while STACKFRAME_SIZE_ON_STACK is 16 due > to 8 bytes of alignment padding. > > The stack unwinder does 'frame = (struct stackframe *)fp - 1', which > reads from 'fp - sizeof(struct stackframe)'. On RV32, with fp set to > sp + STACKFRAME_SIZE_ON_STACK (sp + 16), the unwinder reads from > sp + 8, which falls in the alignment padding rather than where the > saved fp/ra are actually stored (sp + 0 and sp + 4). > > Fix this by introducing STACKFRAME_SIZE (the unaligned sizeof) and using > it for frame pointer setup and restoration, while keeping > STACKFRAME_SIZE_ON_STACK for the stack pointer allocation/deallocation > which must remain 16-byte aligned. > > Signed-off-by: Rui Qi > --- > arch/riscv/kernel/asm-offsets.c | 1 + > arch/riscv/kernel/entry.S | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c > index af827448a609..c1b5f7eb03fd 100644 > --- a/arch/riscv/kernel/asm-offsets.c > +++ b/arch/riscv/kernel/asm-offsets.c > @@ -500,6 +500,7 @@ void asm_offsets(void) > OFFSET(SBI_HART_BOOT_TASK_PTR_OFFSET, sbi_hart_boot_data, task_ptr); > OFFSET(SBI_HART_BOOT_STACK_PTR_OFFSET, sbi_hart_boot_data, stack_ptr); > > + DEFINE(STACKFRAME_SIZE, sizeof(struct stackframe)); > DEFINE(STACKFRAME_SIZE_ON_STACK, ALIGN(sizeof(struct stackframe), STACK_ALIGN)); > OFFSET(STACKFRAME_FP, stackframe, fp); > OFFSET(STACKFRAME_RA, stackframe, ra); > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > index d011fb51c59a..e8b654e2b7b5 100644 > --- a/arch/riscv/kernel/entry.S > +++ b/arch/riscv/kernel/entry.S > @@ -383,7 +383,7 @@ SYM_FUNC_START(call_on_irq_stack) > addi sp, sp, -STACKFRAME_SIZE_ON_STACK > REG_S ra, STACKFRAME_RA(sp) > REG_S s0, STACKFRAME_FP(sp) > - addi s0, sp, STACKFRAME_SIZE_ON_STACK > + addi s0, sp, STACKFRAME_SIZE > > /* Switch to the per-CPU shadow call stack */ > scs_save_current > @@ -399,7 +399,7 @@ SYM_FUNC_START(call_on_irq_stack) > scs_load_current > > /* Switch back to the thread stack and restore ra and s0 */ > - addi sp, s0, -STACKFRAME_SIZE_ON_STACK > + addi sp, s0, -STACKFRAME_SIZE > REG_L ra, STACKFRAME_RA(sp) > REG_L s0, STACKFRAME_FP(sp) > addi sp, sp, STACKFRAME_SIZE_ON_STACK