From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 02451C3DA64 for ; Wed, 31 Jul 2024 16:10:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=A5a8g+BWK+cNaBpoowqPbxVNMmfNvlzHRbZrs2QOGGs=; b=pS2ggKEdgKU/8QVgQCrcaB7NUY +RcsYMe9563+Pxp5mQX0NuSuj9MmYrUW9R5Hc7Pcg47hwstBwU2SwpyVP4zE0jJ5cXWGDqt3zWeZ/ o9xVbhkfoIBNO649PgOpubjK6WiyLoOQQ7vbtr8r5hQhNEyseTdoIuCVABbb5lZvbNz8xk21ajj8u yFCy2Sq3MtkWrPSo03Z/oW9+ousZExNLFfAG0L87taRe7DoMVCLkwwReLFgSAZCSJWHigYEjbnf8M 832hsq1gVsN9K6nbGdWsZpcnSZy8YPV77fXzc6chWMqBUnEWJHPjgGCJEyzWfIwfo1UVAIELljJZz FAMUR8iQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZBtz-00000001oz5-2syB; Wed, 31 Jul 2024 16:10:11 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZBtW-00000001owg-3xmS for linux-arm-kernel@lists.infradead.org; Wed, 31 Jul 2024 16:09:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 84FFA1063; Wed, 31 Jul 2024 09:10:05 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F1B3E3F5A1; Wed, 31 Jul 2024 09:09:38 -0700 (PDT) Date: Wed, 31 Jul 2024 17:09:36 +0100 From: Dave Martin To: Mark Brown Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Joey Gouly Subject: Re: [PATCH] arm64: signal: Update sigcontext reservations table Message-ID: References: <4beceb69-b66d-43cd-89ca-0a3eed6b4ccc@sirena.org.uk> <4c847f4c-6a99-49c2-a3a9-60c1e30a4e7b@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c847f4c-6a99-49c2-a3a9-60c1e30a4e7b@sirena.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240731_090943_225569_F69FA5C2 X-CRM114-Status: GOOD ( 19.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 31, 2024 at 03:58:00PM +0100, Mark Brown wrote: > On Wed, Jul 31, 2024 at 03:38:40PM +0100, Dave Martin wrote: > > > For the patch itself, can you say whether the proposed update is right > > or wrong, and whether you think we need to document this better and/or > > change the approach? > > I haven't double checked the sizeofs but it covers all the things in the > frame and like I said before there's no exclusion between PSTATE.{SM,ZA}. > I do think this should be clearer about what it's supposed to be > tracking. > > + * where vl is the non-streaming SVE vector length, as set with PR_SVE_SET_VL, > + * and svl is the streaming SVE vector length, as set with PR_SME_SET_VL. > > I'd just say VL is the vector length, that's the term the architecture > uses and it says it's set with PR_SVE_SET_VL to clarify. It's the worst-case sigframe size that we care about here, regardless of what code a signal is delivered in the middle of. Surely that depends on both vector length settings? PSTATE.SM and .ZA can be twiddled on and off in userspace by the compiler IIUC; other translations units aren't supposed to care (or notice), so we can't know ahead of time which vector length setting will be used when generting the sigframe. User code allocating the stack must assume the worst. Can you think of a description that clarifies this? Cheers ---Dave