From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 BC523344DAA for ; Mon, 22 Jun 2026 18:08:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782151717; cv=none; b=iPmlnRQIwBIXqz0lF7r9TzfcA3ZWT5PvLYpO8Z14TCMVFolo5zphXj/33VEI+PQVZ11Tg2zjF6VatCAaZ976ZfwA75BEi0tJiHEqO7Mtjm1KBfbeOJBOsgK2bGgRuVx8YX/XMVcJtRMamORmqmb8L2Ck/AdgooI9SX6ceQHDObc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782151717; c=relaxed/simple; bh=a+9pzTDgWMVrpwDHbO+zkXyeToIY0XDwdfmdKhbJJ0Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IvZMvC858MhHosJ2AjQdEq5wCM3Lvzcc8BfhILjshgdeIiMFHU5KmK9UoFUke3974/cf+yIOR7lGsXWl6/LLHPXrJGkzxuoZktEXexXmsVCBKaFdG9QB3hKB+vtToDR1P33n/hk8jKmgJCVKghSMZvC8vqVa/3gGBItRfI/w/ZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=3xmxTP8s; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=+jfxFsaL; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="3xmxTP8s"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="+jfxFsaL" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1782151713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0RAcSN4Jyp8r6M0x8JyWR8gtgPSXUUxipoPgGSKt5is=; b=3xmxTP8sdaIJBm0i8KnU66mKd/STCYGyFd0ubOGffdrYoH1h2gI1KBGC4AgMg2+Cxlf/5F OcA4XhmK8EuWuXE56cf+Xc5bDBPtbs3upPcw0dDQZpYb87s6V6YjqbFj/B8U3gjD4gY+od 9xeBkLIldlXe5Wl06QtlbEwYiX6T4lFx/cZ8Ckq6hFax1yKdPIqPLgMJEQpSbVX4LwroBz 4fxWDTK2DhYxv8D/v+u2UrxVbk3hp23ZXVN11AY7UYlsrv+HzS29CuMNz+DwwSlz34zy8m H7hJYYM0fwXOgTePte+WxxOUX5HpOUQWosdF5OKWrzS4MrvTCtfw0f/SLpobfw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1782151713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0RAcSN4Jyp8r6M0x8JyWR8gtgPSXUUxipoPgGSKt5is=; b=+jfxFsaLB3ytIXGCVUnAlf8WfyPLSZSDlIOTZBUuDbvsq5fnQiMMJPAE3XLgBRT4/dWrly NhKiVwXs1z5tWqBA== To: Rui Qi , palmer@dabbelt.com, pjw@kernel.org, aou@eecs.berkeley.edu, alex@ghiti.fr Cc: Rui Qi , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] riscv: fix frame pointer in call_on_irq_stack for RV32 In-Reply-To: <20260603035305.564823-1-qirui.001@bytedance.com> References: <20260603035305.564823-1-qirui.001@bytedance.com> Date: Mon, 22 Jun 2026 20:08:31 +0200 Message-ID: <87h5muv468.fsf@yellow.woof> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Rui Qi" writes: > --- 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 Doesn't this break the calling convention? The ABI specifies that "After the prologue, the frame pointer register will point to [...] the stack pointer value on entry to the current procedure". The frame pointer is already correct here. It is the storage locations of ra and fp that are broken. The ABI says "This puts the return address at fp - XLEN/8, and the previous frame pointer at fp - 2 * XLEN/8". Or am I confused? Nam