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 72261C531DC for ; Tue, 20 Aug 2024 17:07:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0239B6B0083; Tue, 20 Aug 2024 13:07:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F168A6B0085; Tue, 20 Aug 2024 13:07:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDD3C6B0088; Tue, 20 Aug 2024 13:07:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BFE9F6B0083 for ; Tue, 20 Aug 2024 13:07:46 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4B488403B2 for ; Tue, 20 Aug 2024 17:07:46 +0000 (UTC) X-FDA: 82473255732.12.B9ACE9C Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf27.hostedemail.com (Postfix) with ESMTP id EB6B74001C for ; Tue, 20 Aug 2024 17:07:43 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724173648; 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=aQyEuqNnkwz3WhAvQ9OyOp/Y67j7xpvJJsdkhU7zjKs=; b=Q+kYof6dNL04WsdoisTjRU6IAwJng6XVhMbzdYWVNswh8jX4tUc2DgYSzCp0EWi1hmCn34 qtmD1I5QYLMWqNg2US0PzeHV1Z4F3T6RYt6sIRqmd/TLLtedpRJxcp+3aDtY746HVhCwLu j3E1t/4DAezry5WbcMZxw977H5gww5U= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724173648; a=rsa-sha256; cv=none; b=ptiFnPBEjx5hreF3BKoR98nEsWo9U0IzaY1ERMAlisa6/088R+wPYCB35AdMODepuu+WqC TInYBl8yFxPKLRPgD1IxG/0FSmg0cPnw0xaf6gVxxEZd/oy12ohUMStFSIvQLHXvnd7Vrk UhFLPdTsRbYJaIvtJhBNWvy+PQf9WNs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id E1875CE0AE7; Tue, 20 Aug 2024 17:07:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6B55C4AF13; Tue, 20 Aug 2024 17:07:31 +0000 (UTC) Date: Tue, 20 Aug 2024 18:07:29 +0100 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Thiago Jung Bauermann , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v10 19/40] arm64/gcs: Context switch GCS state for EL0 Message-ID: References: <20240801-arm64-gcs-v10-0-699e2bd2190b@kernel.org> <20240801-arm64-gcs-v10-19-699e2bd2190b@kernel.org> <0f6fd3ec-2481-4507-af0e-3cbbb7406b54@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f6fd3ec-2481-4507-af0e-3cbbb7406b54@sirena.org.uk> X-Rspam-User: X-Stat-Signature: znncu1i6a71gxim1sm4iwwpihmckhwpu X-Rspamd-Queue-Id: EB6B74001C X-Rspamd-Server: rspam11 X-HE-Tag: 1724173663-695631 X-HE-Meta: U2FsdGVkX1+RGLEs+m8SP7PlCR6OX9zboTveeHRdIxqKfDDcxtpEiabV0eBUem6q3wcpS28urIme7ozPsdFAQrRRV8pwVni0SmV41VYRrAFgX+/EfkseM+CDm4nEDrHADnuSCkQSdlw89ubOilhhNGjh9P7Y29UOpHvpTBd2kf2suXl6Atei5W4+N/wEhGrUdhEOwcfNRSywxF2bajVvXOnbWwCfYw/M8XhFGubMO4wKDEYBxIaGwPVwdV5quNrgffOX2g+OdmKUaBPnLCWj9O7sezjsKQvktKfzeHOJQze6t0p9jEBsxcNVlDbkqmYJQ8po/ELpLZc+aZgCcHenpmBxmpFgpAZhfun+85uWt/uy3kM9gT4Dw2kmOKNoEnE21Jr/DtmMY8wixwWbyp7vg57ypE7j7hITrc3FH0DLHTrLbVLHlCT28lVw/xavSLRjeLG0DBQFKHxZZKZD6KYng8GUCbKZdevLQXXju/r6mUTbqKZ2pNJsnPYITUEFX505X5vZmx9lGkeq/QtkCm8AK5MSFHFR558qSaXzRDdd3FP1yZvmqQjt42Ecfk5RNAbOVoNA/+xki4TbhHyVmdV4TWCW1+Zi7mK/AaN0Z0NCnZhhOAu3w/SgNsgq3RUnoD8N5Wz7J/al14fk6+Vei6j/I08Mzze5SL46wobAMw3ukt9aEr9d1vjiPhpsUKsNf456HWXwlPQ+kOV/EN7slgIBIu0PpoUzZFbNRO+1v+DPAR3pSQ4O96jWIwmRrvZ2voZX1i8WaJcQUllttB8hpNeJ9ZD06L/aKMseFc4xmmmSm403DKjJFhrMxluCtaJvGhdLPDzjr5VtswUrl36H8zKxTGqBfQPvzTQtH6iEUeY1lIBgF065TRvhqGUCH/ZftfHDn9nw9hoHBfsuUmW54IsBVhJU8EEbYnXklrXevDsSat2z7DgAUAAnj/+7jc5lHhxXHB4fuRQljyR8A0Tfh9f rxSQj0z5 nvM66mYq5vZONRE2Zd46qYabpMSCmrjfPwhoHb9zMHP6Rnj3tqOWhFxUf2wriMXe1FIckfAmNnHctPcBWYBJMBWpstpfkmHu0ZjMzwrA9zZqWf36ktPJ4e0+EmkEY18psEfFdnwELIe1Eoo3Kn0RAgPcOqiSbsMnQAxrQ/nrw6nyymhVvKrF8AH73wl+bYX8FsBOw1bDK6JqYnCEC758PNLTx7Ymh3z27YqXDv2rGNXq1XRvVwVd4kyce10dFzMXGBjDTKNBUa9hU3+KiUDfDZEJQuklHVP9dcy9btSqR9rlvVJv3svsm53MnCDiIBeJIHTOc5aGgGAMj7zskY+Dc2/Bh983azyiAWEvGLJuKOwEhDJGctJaWY2pzu5jStHxxSWchcW94msE9F49/4vbx2AcVe7HNW5aKoyj1 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 Mon, Aug 19, 2024 at 04:44:42PM +0100, Mark Brown wrote: > On Mon, Aug 19, 2024 at 12:46:13PM +0100, Catalin Marinas wrote: > > On Thu, Aug 01, 2024 at 01:06:46PM +0100, Mark Brown wrote: > > > + /* > > > + * Ensure that GCS changes are observable by/from other PEs in > > > + * case of migration. > > > + */ > > > + if (task_gcs_el0_enabled(current) || task_gcs_el0_enabled(next)) > > > + gcsb_dsync(); [...] > > What's the GCSB DSYNC supposed to do here? The Arm ARM talks about > > ordering between GCS memory effects and other memory effects. I haven't > > looked at the memory model in detail yet (D11.9.1) but AFAICT it has > > nothing to do with the system registers. We'll need this barrier when > > ordering is needed between explicit or implicit (e.g. BL) GCS accesses > > and the explicit classic memory accesses. Paging comes to mind, so maybe > > flush_dcache_page() would need this barrier. ptrace() is another case if > > the memory accessed is a GCS page. I can see you added it in other > > places, I'll have a look as I go through the rest. But I don't think one > > is needed here. > > It's not particuarly for the system registers, is there's so that > anything else that looks at the task's GCS sees the current state. Ah, so that's the to ensure that any writes on the CPU to the GCS stack would be observable if the task appears on a different CPU (together with the additional classic ordering/spinlocks used for the run queues). Maybe update the comment to say "GCS memory effects" instead of "GCS changes". I read the latter as GCS sysreg changes. Something like below would make it clearer: /* * Ensure that GCS memory effects of the 'prev' thread are * ordered before other memory accesses with release semantics * (or preceded by a DMB) on the current PE. In addition, any * memory accesses with acquire semantics (or succeeded by a * DMB) are ordered before GCS memory effects of the 'next' * thread. This will ensure that the GCS memory effects are * visible to other PEs in case of migration. */ Feel free to rephrase as you see fit. > I'm pretty confident this excessive, the goal was to err on the side > of correctness and then relax later. I think we are missing some. Paging should be ok as we have a pte change and TLBI and IIRC the same rules as for standard memory accesses apply. ptrace() memory accesses may need something though I'm fine with considering this a best effort (we can't guarantee anyway if any accesses are on different CPUs). I haven't got to the signal handling patch yet. -- Catalin