From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 DF1DB36EAB2 for ; Thu, 25 Jun 2026 20:52:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782420755; cv=none; b=o91FE72FHXMBDMkCTh6s6eQIIJegm7vZv07aFQEDlsBw4hOt2oboqXweKfly7NvrWZgaaJsODepWi/4hyOXUoHof2FxOQCZMDDx6vOsccx/Epz8O2DJ3VxchhyBdDOqrgYE4QPOLTpk07uCirPRGQU2JAiP/Mm+4A//gs3NhZVM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782420755; c=relaxed/simple; bh=33eudkd6O2N/Vt7J+Mnjq89wR8qRMDUZkovWW5rKkX4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qvdvXotFVbKpvEp9BseWOvadTZHQnbAFzbT5y1nX0+FptN+ID8CL4jsebzxb6XbJuMSGLUVOY0ct1skW5A9ULQqKwv3u6yM8OIGzzERWtU6SUSXww9lGgl6L2td77FvJZVqClU8gtIBIJGwmq55+Q2okYZMCzsaB03DBMjzCLuU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=XOtLzlKg; arc=none smtp.client-ip=209.85.210.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="XOtLzlKg" Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7e6b554044fso202055a34.0 for ; Thu, 25 Jun 2026 13:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1782420753; x=1783025553; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2QpcdarrD5t9c5J5NcdgKMB6+v6n7Sm7nV3q/hZN1Z8=; b=XOtLzlKgZOb37T0P5Ldj7U8bA6EkwErjzEcwEBGluZL227DPv5mecgOx1vgQDrGAGs kkMHwVo0/6x3vMjRrEEmDIMKbD4qUGywrt6L86g2MtpPLzhNnny44RM3w2id6hRl0jhc 5bUeEYKt0DI+7wdH/SfcPd2lP4sblFlniXMPAS9PlT82EW/mKEUGcQI4FIX6qAbX1hj3 hpjoUfNuObahetii65EsAx166IOHRzxoq8etIlLkj9sZ6a4zH/LUWnWNSKiSC2kq2+ae 3nf5EGJC/sa87Ls/sVXOMLu/kYmT8oD2+tykaX79hbgfRe12m+YPXURJ9EHw/N5bHyb2 gzmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782420753; x=1783025553; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2QpcdarrD5t9c5J5NcdgKMB6+v6n7Sm7nV3q/hZN1Z8=; b=SjFK9zEtgfbOCE/d5tLmkwzPV60CIYiDU6q0tt6u6RisE28Yp43eBM7yab8dMFQ+52 0kcb9168xYa48bgPioLBN+q8jYt4ZepLcY8L5Zw1sTa3SHoaFmTnNUYHvsXQ826EwZBD 9xwGhHfZNGwb3E4cmVQM4XXLB5V4MrIINm6QBoDxsbZBrb5MpBoHKYlHq+kRJVjQvsU2 NyvOaczGN3V8pOLrd8FvsALoV1FQKN8ysXcDKQF0Gb4NlbHtEaEbTEUHM09usXxcYPbU XW/bM+t494LcQ1qOi4O9qU6Okc4dL2aXR0BZCIx9Z8KcYFD588/8HBJFYgBGPIFupEUc VLnw== X-Forwarded-Encrypted: i=1; AFNElJ+VuO/TjqY5oJXET9RX35j9IrIyFMZQHei8La+71vQcfMVw4/FM/2RXFJLKu2mULpETDbDd0HlBZ8lkXOA=@vger.kernel.org X-Gm-Message-State: AOJu0Yw/sxSLD55UpSrenl33A8dwMGX6Jl3Qz8BGzTwcdlhfVxY6/8u8 jVjeY4JDed98bnj1XUEbalmHYqc8M7DHYvVN3yYJzgyZOsegil9YvkB3n11AzR5oAR4= X-Gm-Gg: AfdE7cm8m9TnzGQd5CPOOPNy51wqmukkEnTnWqtQT48QZqjlpNbqcf7ikceqcv7L6NX oy6BcngEGCszmRCq2iLQYduQ9k9oS+bKtAxNlVHEWOYTPfWDgQJK/H0aQMdLkanAJCiCTC1iR9i 9CsvHBQZ6oFrXlgSO6k1ibGNfadTrDp4LV+8lqX5r1MyJ8lNlM6m5HbAsRkcmI89diNJH5NMBpv PyX9ZUCGIyqh5l7ftWu4xlZZ2Aymg7tqkEsj1M1im3vIsRFCJvorSvGzj0pPTirarWbNAMrtm3j J3TKOZfEgotKSqgCzoSQIG/fu87VlRaoJD95t//EJ0nRSveT8m1rSfm01BMQ4VQxEzVrIlbtRSB 0W6U2mtu19pMsPZs12yn+14DVXfaL6o7lICfqZjI2p214mwwR+fYxTvZLJ5kdEaVCOxHIggUOtx RimnyhPKLjGueBbtNRQCU8N76bAINNivKq2hPCag== X-Received: by 2002:a05:6830:8295:b0:7e7:352:2f75 with SMTP id 46e09a7af769-7e99c2ccb24mr4213389a34.21.1782420752836; Thu, 25 Jun 2026 13:52:32 -0700 (PDT) Received: from [100.64.0.1] ([136.226.102.173]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e9aa5fe07csm94364a34.12.2026.06.25.13.52.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2026 13:52:32 -0700 (PDT) Message-ID: <8ac42c36-a8b8-4136-8173-c1cfa519cb2f@sifive.com> Date: Thu, 25 Jun 2026 15:52:31 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI To: Nam Cao , 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 References: <20260624113148.3723541-1-qirui.001@bytedance.com> <2e47388a-8883-4b44-b440-a00b8e622733@kernel.org> <87pl1fvwce.fsf@yellow.woof> Content-Language: en-US From: Samuel Holland In-Reply-To: <87pl1fvwce.fsf@yellow.woof> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-06-25 3:49 AM, Nam Cao wrote: > 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. The reason for choosing the definitions in the patch is to match the ABI[1], which defines the fields at negative offsets from the frame pointer: "This puts the return address at fp - PTRSZ/8, and the previous frame pointer at fp - 2 * PTRSZ/8" In call_on_irq_stack(), the frame pointer is (sp + STACKFRAME_SIZE_ON_STACK). So the restore code could equivalently be written as: REG_L ra, STACKFRAME_RA(s0) REG_L s0, STACKFRAME_FP(s0) which is nice and clean and works everywhere, but the save code can't be as clean due to needing both the old and new frame pointer value at the same time. So it either needs a temporary register for the new stack pointer, or to do the calculation in the assembly, and I chose the latter; and I preferred to make the save/restore code visually consistent. [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc#frame-pointer-convention > 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. Indeed, a later patch in the original series allocated space for both struct stackframe and struct pt_regs at the same time. Regards, Samuel