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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E480C3DA4A for ; Tue, 20 Aug 2024 13:55:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E822E6B007B; Tue, 20 Aug 2024 09:55:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0A786B0082; Tue, 20 Aug 2024 09:55:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAB716B0083; Tue, 20 Aug 2024 09:55:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A8F816B007B for ; Tue, 20 Aug 2024 09:55:01 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 541EDC01BD for ; Tue, 20 Aug 2024 13:55:01 +0000 (UTC) X-FDA: 82472770002.09.C0C8A18 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf07.hostedemail.com (Postfix) with ESMTP id 7675C4000A for ; Tue, 20 Aug 2024 13:54:59 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724162021; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3RkKikSNRfciPJo+ccpSqcraEUOr2naNaUvt6mvvnKc=; b=S+GJ9wnrnDztMxBbHlYaVLSXCSZjg8iHWmvmStVbxUEdKMezR1WaZmkFWy3Pp10N418rVV LVbsZy7TLQdX5CcRlyRak5KOsi2uhnD9KSQnKmD53C6yjoYAG4uvYky9sB80Fj5kirO9Jk RUlOnrAGpZTXA0Vbwysjbt2lM2yhJg0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724162021; a=rsa-sha256; cv=none; b=XDV3YEWn7QGugEyZ5vw0OjDWsjEKguvuad6iUDt5DQdfJYhm4tz/f4DyUWffE/RDAZKCE4 9gkQgRa6Yl6UrJBQbhbshdcEDGG9ZRtClZGAxJN5ztcvAJryBSqtIFPcGTErB8TOptyyK/ aecAjOP4DOFOOJxlDq/vau8PcXKqu5g= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of Dave.Martin@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=Dave.Martin@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 5A545DA7; Tue, 20 Aug 2024 06:55:24 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5460C3F66E; Tue, 20 Aug 2024 06:54:55 -0700 (PDT) Date: Tue, 20 Aug 2024 14:54:50 +0100 From: Dave Martin To: Joey Gouly Cc: Catalin Marinas , linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, bp@alien8.de, broonie@kernel.org, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, szabolcs.nagy@arm.com, tglx@linutronix.de, will@kernel.org, x86@kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 18/29] arm64: add POE signal support Message-ID: References: <20240801155441.GB841837@e124191.cambridge.arm.com> <20240806103532.GA1986436@e124191.cambridge.arm.com> <20240806143103.GB2017741@e124191.cambridge.arm.com> <20240815131815.GA3657684@e124191.cambridge.arm.com> <20240820095441.GA688664@e124191.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240820095441.GA688664@e124191.cambridge.arm.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7675C4000A X-Stat-Signature: my81ftrp6anm1qcou7q53fmesb9oaz6y X-HE-Tag: 1724162099-262946 X-HE-Meta: U2FsdGVkX1/byDnHAkkXDdzP2hr49utk2pIwNH6wlbX0aPL4TyDOMDSwOmG9Yshwora4zMVyxbgD012+U2HCLAEqk1qhyesI0boZFJF95fnLgaRSd8GPnAfK3jwdTEcFsot/0CnRjvvG0jheaZQa1F0hAbfvbX/83vQUp1MfP3gA9scyk4VnBYnmw1aBq9I6p745Kt4DHDK0dCMSVXdvl2dRyLnTMDVGAzROQvGAmVMwBzzQhjmORfOQuE4jjRJBdAFr6FOn+x5EiuEWqcvqDgpNwj+cH3RkvIvMb4kzx0QdeBy3PZXLNl6KE5frVuQ4i4x9vrlWXdKpVht3euyK8uHsRPaww+zvinV2rZ3ANvA3qF4C32qhm+1yOkVknR38BiibsIjPTd8V0RfM0nYKjA5BXnI2BRzxlprBYiT4T1m1mLt83RB2/iMcFhBxtsG/hko5FnPTCEwAQiMsBBEvjQa/HzD01FuEAjWfmGv3pd5tMcQpTNOTMFr9mhv/OpZ2xeDDFM+gcU95ETLo9oYbysbDz4q3LC8KAh3lp8TNQLg/sgMiOPIPvnljHyM1qsKMiiY1mIpOyJ3nLk1JgNcYI9o+y0QRESvczMjzgPmaNpVtuYVeVUZLuiZUdpz8P+12BzY/m1T0r+LUQU3nLykj5SlkHJJSTREqfoGAUN6rUJPXTtVCNv85kc2XQr9aoGzDcA0Il6jfvFRHOXiXGL6BuGppSqVTlRB7uRTt25pG4HfrY1HhUxZ+V0pb7K7QfANwXKTJc3fJtSw74T/zNv824+Bqd9WqVT3Sig+TFHZTp85jn24ian3QaQvoOeljDBH92FSGi12RDEhmpXYUgiHG1rslmk2Dbi8IfNjbVuzQDev7zz2nC8lASN2fF9nDmidWZRntRgWaFvh8URaLj9mxHxPJ66gUHuDmgkTYFqlSbNQJVoomfwB3fGkuV1+rRY8TPizbgE18y8wYcbJaRyy OgvR/msZ Uv8uvxwIg7I8COAhtH8fCTMUGXr4Ue2tSLKkYvGP4c47+SNfBfAX3DK2KAo224b3ir3U0meI574VeMFyEnNFVPpH500XmLAR7ldvyi9F8toaLIdNTv7M0hJxlBkHdedzMo15rJXQXbAfTk6203rDaUbYIPg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Aug 20, 2024 at 10:54:41AM +0100, Joey Gouly wrote: > On Mon, Aug 19, 2024 at 06:09:06PM +0100, Catalin Marinas wrote: > > On Thu, Aug 15, 2024 at 04:09:26PM +0100, Dave P Martin wrote: > > > On Thu, Aug 15, 2024 at 02:18:15PM +0100, Joey Gouly wrote: > > > > That's a lot of words to say, or ask, do you agree with the approach of only > > > > saving POR_EL0 in the signal frame if num_allocated_pkeys() > 1? > > > > > > > > Thanks, > > > > Joey > > > > > > ...So..., given all the above, it is perhaps best to go back to > > > dumping POR_EL0 unconditionally after all, unless we have a mechanism > > > to determine whether pkeys are in use at all. > > > > Ah, I can see why checking for POR_EL0_INIT is useful. Only checking for > > the allocated keys gets confusing with pkey 0. > > > > Not sure what the deal is with pkey 0. Is it considered allocated by > > default or unallocatable? If the former, it implies that pkeys are > > already in use (hence the additional check for POR_EL0_INIT). In > > principle the hardware allows us to use permissions where the pkeys do > > not apply but we'd run out of indices and PTE bits to encode them, so I > > think by default we should assume that pkey 0 is pre-allocated. > > > > > > You can consider pkey 0 allocated by default. You can actually pkey_free(0), there's nothing stopping that. Is that intentional? You're not supposed to free pkeys that are in use, and it's quasi- impossible to know whether pkey 0 is in use: all binaries in the process assume that pkey is available and use it by default for their pages, plus the stack will be painted with pkey 0, and the vDSO has to be painted with some pkey. Actually, that's a good point, because of the vDSO I think that only special bits of code with a private ABI (e.g., JITted code etc.) that definitely don't call into the vDSO can block permissions on pkey 0... otherwise, stuff will break. > > > So I agree that it's probably best to save it unconditionally. > > Alright, will leave it as is! Ack, I think the whole discussion around this has shown that there isn't a _simple_ argument for conditionally dumping POR_EL0... so I'm prepared to admit defeat here. We might still try to slow down the consumption of the remaining space with a "misc registers" record, instead of dedicating a record to POR_EL0. I have some thoughts on that, but if nobody cares that much then this probably isn't worth pursuing. Cheers ---Dave