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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D81CEE49B0 for ; Wed, 23 Aug 2023 16:45:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234985AbjHWQp3 (ORCPT ); Wed, 23 Aug 2023 12:45:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231450AbjHWQp3 (ORCPT ); Wed, 23 Aug 2023 12:45:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3183A11F; Wed, 23 Aug 2023 09:45:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B31066487E; Wed, 23 Aug 2023 16:45:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 676D7C433C7; Wed, 23 Aug 2023 16:45:15 +0000 (UTC) Date: Wed, 23 Aug 2023 17:45:11 +0100 From: Catalin Marinas To: Mark Brown Cc: Szabolcs Nagy , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , 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 v4 03/36] arm64/gcs: Document the ABI for Guarded Control Stacks Message-ID: References: <20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org> <20230807-arm64-gcs-v4-3-68cfa37f9069@kernel.org> <43ec219d-bf20-47b8-a5f8-32bc3b64d487@sirena.org.uk> <227e6552-353c-40a9-86c1-280587a40e3c@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <227e6552-353c-40a9-86c1-280587a40e3c@sirena.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Wed, Aug 23, 2023 at 01:51:35PM +0100, Mark Brown wrote: > On Wed, Aug 23, 2023 at 11:09:59AM +0100, Szabolcs Nagy wrote: > > The 08/22/2023 18:53, Mark Brown wrote: > > > My sense is that they deployment story is going to be smoother with > > > defaults being provided since it avoids dealing with the issue of what > > > to do if userspace creates a thread without a GCS in a GCS enabled > > > process but like I say I'd be totally happy to extend clone3(). I will > > > put some patches together for that (probably once the x86 stuff lands). > > > Given the size of this series it might be better split out for > > > manageability if nothing else. > > > i would make thread without gcs to implicitly disable gcs, since > > that's what's bw compat with clones outside of libc (the libc can > > guarantee gcs allocation when gcs is enabled). > > That'd create a pretty substantial divergence with the x86 patches if > they land this time around, there's not enough time to rework them now - > I suppose it'd mainly bite people implementing libc type stuff but > still, doesn't feel great. I don't mind the divergence in this area if the libc folks are ok with it. x86 can eventually use the clone3() interface if they want more flexibility, they'll just have to continue supporting the old one. I think we already diverge around the prctl(). -- Catalin