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 EE8EC32B112 for ; Thu, 25 Jun 2026 08:49:07 +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=1782377349; cv=none; b=RFBJjV9oC9/PlmNA9erEVO4O/RIOU7a82hEBMDBDroyNzN44ceBhfghEs3ozIK8PuWoWa/WrmMmpDG3Ibv5EUDqRdFE4ndu3UgYvlwQmfewZYeY/JvvQSFYq6ynBahSZJamHMRIbfV9nHkVigaLlLOD+25OCTkkqQOxgtFNEVng= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782377349; c=relaxed/simple; bh=m6EuEiCv6A7qeNjMlLxc951+9yaRKE3Op2sI2WDwPfw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Md1KnxGAc9pvGNoJ/s2MSGNIvc1Z2wHUkBu1wyA30ejt/XwWq0fJCojT22bF6u5lsQlGqEquL5m2eCqKh41LtbyF0EgxE1/Ks3lXcCObZIwYD7rWrjr76aZMwY6wKlOeeTWlVUQ+O4MoH43hnkP6wu8tU+lpLGyzmTlh6SYbjwM= 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=TbtMD0J7; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=vwmhRcnf; 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="TbtMD0J7"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="vwmhRcnf" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1782377346; 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=CH2pCCXt5kqod2CyOIkwzroP+4v71HSKPpSDEHo8rcw=; b=TbtMD0J7g/R4Uw+RkH5qfOreFOOYyqsOER3GSvIfvyoAvRbuSaTb9Ccqu3FHLDWmSNpBdC ZPtYA//tgi/Vvi6I6Wfpvn1m3C89eFgCGrsGSsrr+jYxqkzZ44+3ddCwORtLYCt2Pz9vIJ jTgyReZ1sUUskOJs3CmN4Ob84dVxYDf288rzQPXQufDAVsyySkGtzkE0xDDyGHnPYuYmNj U2rTXFg38YbH7HUhql3QWo/Gs57m50Fz7dT70WqtDHhOrnnF2kwhibB3MIU5ijZrU0RlXD EIBNfw9bIhWTbHVGmUcSv7rxRqxdfBcspneDxogWNv9aIj4Z7vPegiayQ/VFmw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1782377346; 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=CH2pCCXt5kqod2CyOIkwzroP+4v71HSKPpSDEHo8rcw=; b=vwmhRcnf4gj5RyGzSPY4CXrQM/apW4IJ7nIHin4pgmIcYedDnHRugW1ruGzl1F1ZSLoWLN VAT0sy+vRUoPxwCA== To: Michael Ellerman , Rui Qi , palmer@dabbelt.com, pjw@kernel.org, aou@eecs.berkeley.edu, alex@ghiti.fr, conor@kernel.org Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, samuel.holland@sifive.com Subject: Re: [PATCH] riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI In-Reply-To: <2e47388a-8883-4b44-b440-a00b8e622733@kernel.org> References: <20260624113148.3723541-1-qirui.001@bytedance.com> <2e47388a-8883-4b44-b440-a00b8e622733@kernel.org> Date: Thu, 25 Jun 2026 10:49:05 +0200 Message-ID: <87pl1fvwce.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 Michael Ellerman writes: > On 24/6/26 9:31 pm, Rui Qi wrote: >> call_on_irq_stack() uses struct member offsets to set up its link in the >> frame record list. On riscv32, struct stackframe is the wrong size to >> maintain stack pointer alignment, so STACKFRAME_SIZE_ON_STACK includes >> padding. However, the ABI requires the frame record to be placed >> immediately below the address stored in s0, so the padding must come >> before the struct members. >> >> Fix the layout by making STACKFRAME_FP and STACKFRAME_RA the negative >> offsets from s0, instead of the positive offsets from sp. > > The fact that all uses of the defines need to add back STACKFRAME_SIZE_ON_STACK > makes me think the defines don't have the most useful values. > > If the values were offset + padding then the uses could be left unchanged. At the moment we only have only one user which has nothing except the stack frame on the stack. Other potential users do not necessarily add back STACKFRAME_SIZE_ON_STACK. The offset value depends on the function. So I think it's better to leave that offset calculation to users. Nam