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 86006C10DC1 for ; Wed, 6 Dec 2023 20:22:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A1D96B0085; Wed, 6 Dec 2023 15:22:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 22B136B0087; Wed, 6 Dec 2023 15:22:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CBBD6B0088; Wed, 6 Dec 2023 15:22:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F14CC6B0085 for ; Wed, 6 Dec 2023 15:22:54 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CD02512026E for ; Wed, 6 Dec 2023 20:22:54 +0000 (UTC) X-FDA: 81537517068.03.8FD2E47 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf12.hostedemail.com (Postfix) with ESMTP id EEE9C40007 for ; Wed, 6 Dec 2023 20:22:52 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=twX4EhKA; spf=pass (imf12.hostedemail.com: domain of thiago.bauermann@linaro.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=thiago.bauermann@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701894173; 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:dkim-signature; bh=wEKgHh9Vd3x1VnCH3fKyTqAO4yCFQDcZVScsz606mCI=; b=KXoe52ZG7bwaOXWzMlgAZxF1F4rWTkWg06qnX11snumBmH00GSBpBrlFgXQ0o7BlviXHlF uwbgHsuCRTOtEM4o0dTS2ZuMJLltq22VLsLZnVlkejXiakLX0xZZx7VaOndYZa2sedKXeU wXe17n47uGiV/L8ag/D4MVzKnV1dwVo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701894173; a=rsa-sha256; cv=none; b=EAg1bM+JHjY2DAXdBlC6rfyVyP0JXw2YGMd9U4qq2fsUrvOvog1++XW2M+fPFhMJK+5yIN dh//DER1NkMwgDDfrHcX/EmmjxButVr67ffBEucrKbl53XMYNAUJ96WSoPM5viO7dTvtSi nQh1nCDaSe/58hXoDs9zXEvyJxxrkIg= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=twX4EhKA; spf=pass (imf12.hostedemail.com: domain of thiago.bauermann@linaro.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=thiago.bauermann@linaro.org; dmarc=pass (policy=none) header.from=linaro.org Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1d06d42a58aso1540575ad.0 for ; Wed, 06 Dec 2023 12:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1701894172; x=1702498972; darn=kvack.org; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=wEKgHh9Vd3x1VnCH3fKyTqAO4yCFQDcZVScsz606mCI=; b=twX4EhKAkif5OhifzXt5HdSto1JPIOMUxAH9ekOU1H3PMx4zIZe4lPDACgvKwZ4B+m Bdk5fYuL62O6kKaW409E+k+im541YMozMlfepEC/cLyUnrfUYGTFh4FHkkRRHfl/3rnc JWHxKVcr3SvMNb4/hhMPmVz4OMM6Dj8JDyFnEQWVRr7xJEziFVnW3OtSvz/mMlqLjZgB NHGY6A97muCFMf3rSCzdx2z0oJ5nqE1oXnnQv6hrg9+8cE8Sft0jovS+U4k6hMM3Irdt 5pvGTCvLDIln+kz0NsCXPkPfwhjwSLxNyImc8KW0UrllvPY1kogZw0PWKPFFreGLjGd/ ELKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701894172; x=1702498972; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wEKgHh9Vd3x1VnCH3fKyTqAO4yCFQDcZVScsz606mCI=; b=isErNWf8SEF2Z/0xEu2IEfgRdcwe9qMRUhWbzNiGlk0/zLwEQcCUAjwyUUUZB8NJDv fch4CYZcCfPG3FB2mYb+hS5l6wdDDJ34XqpNtKPeqFNqDuYRRQ0iS934XRLmsdgzdyNa /ys7D4Fo5w32jjAzwTr69p5eIm3rPwSoCHG70OXF17NEXFWz+ZPag9DrUVP5W2crxuVI 5sH2+Ymd6VSAMrkyc2KmhtzoQNFQ5TXO3ZntJGe7xtOUHctqzaFG0V6jGX3DMI6X6sfU XdfWZb7A6LZyJFn9+aC0j0H660DdSA/7fc9hGzXKoKIrE8xOAKCXB8+/jSVANftVrCq+ UNSg== X-Gm-Message-State: AOJu0YyvIFSEpjvqZZHxz9VjeIADDGOf56Jb6kK93/y+7S3cLmucD/dw y32brRamcFyqmfqCSYEhanPFmg== X-Google-Smtp-Source: AGHT+IG+PGi/Ruq72+ftbttXAOwy9ae3wKn38k1eINbZqpLAyVIquTjmRIENSAWXjKXoIaCS0/BIwA== X-Received: by 2002:a17:902:d502:b0:1d0:92a0:492b with SMTP id b2-20020a170902d50200b001d092a0492bmr1505448plg.84.1701894171625; Wed, 06 Dec 2023 12:22:51 -0800 (PST) Received: from localhost ([2804:14d:7e22:803e:f0e2:3ff1:8acc:a2d5]) by smtp.gmail.com with ESMTPSA id z2-20020a170902ee0200b001d071a305ecsm217078plb.245.2023.12.06.12.22.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Dec 2023 12:22:51 -0800 (PST) References: <20231122-arm64-gcs-v7-0-201c483bd775@kernel.org> <20231122-arm64-gcs-v7-21-201c483bd775@kernel.org> User-agent: mu4e 1.10.8; emacs 29.1 From: Thiago Jung Bauermann To: Mark Brown Cc: Catalin Marinas , 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 , Szabolcs Nagy , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , 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 v7 21/39] arm64/gcs: Allocate a new GCS for threads with GCS enabled In-reply-to: <20231122-arm64-gcs-v7-21-201c483bd775@kernel.org> Date: Wed, 06 Dec 2023 17:22:49 -0300 Message-ID: <87il5bhyhy.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: EEE9C40007 X-Rspam-User: X-Stat-Signature: bzutmhbw1ogi9gbwzwcyfq8dwuq6rrua X-Rspamd-Server: rspam03 X-HE-Tag: 1701894172-59700 X-HE-Meta: U2FsdGVkX186HR4meAKIE+0zgdiLzSgnsShQrytFilVTZt2JPsK+T9T9UR/KHJ5EK3VhtX2vki5ho2WhCMTUl4L7paLQ9uzyHz/bFBSEQHeDFRi0PX/1EbZ8RdyoLpg2Q87220XXS1GhX363MbwY9PqE7GoaRJP7tjF496+Gw7WrNAy8SZMt1GTCFNy0xaAMDF7W3wcUTX05cIlaFfc9uvNhmdm/6m37i02bAftsWWak7KcLmxk7Cye5b+Hy8sHTlDkI561fiLcsDO0N4+oqPCWEayo3N3HzYifEbvsZD8podQEnO77yFr/1wAeFdQZmUFa7Mv/PoxS3JNyIdzuKClQdbmx0uTSijb+T5zxNlJwZZQu0cakthywKgWbIb8721shCq+mNeuVRYgL91y8Vxdgo1AZyrJTCDn8FpN9BgG3G6tFhtiknoeK0lILiG85UE7a8nqbGwwA0AcLHMSIMgItKxDldt5EoakKAPJgdVEFuaZnqCL7q+krq2ZP8kXqWj1wwEMOktcEdPhdvC4yAGLtXDnsuZ26JHbMRN++cNt8UGq4DHBl2/7vhsVM1psxXAM1sV4+8C77rGNfaPnRIGpanmkhkFf2cAiaFZQTNpbknZuovVK6Tc6gpj++ZXi6mQkoHFXXmh0hF8i83sSmSvJA4h7kH82WBSoDU87yHjUEnJCNjiHfKuEhPcYTO/g9nFGdF0qu1iURGNPaN9kjA8vaXjUrB2CS9Awz8LkHiFactA/39uD7rtOD7NiGDirqGQNuqUCPiqxN7fzBLa/6l1lF53ePDpS+J30Yoe2l+goNWliatjYq93Vja0RcwHzGQ/RXcyndqfB9bJe6tt7DRUw+Rs8I7XBbxn/jZBsAUcqqn2D1110S8BnD5ygS4dtFwU1J7eAAd7yqC1CHIZZM9SHL1RUGLJTG+nzwKJUTQckC3c9ZJNJdRQEcaKSVGONBGFB5czvg9JuUOazPtoXd 3Z8auQV/ 8a2aEtaACc/UUNxW2+/M99+60aygtKcX2M4MusnvFI2e0872sc9hPqbsN2u+8yscmxX1jkJKjlfoj2eiJMPx+YaQXBvismI46oPN8BGY70QEiqpvSsxOqKRUFQ9UCq8rh2E5yK33resjVoAHjeqrowvZG3gNf0n5tas6OwHDKIlqzlkV6mIuV7HXXYdmoBOvH5aDb86MkInnEHKUxn6U27T7ypTwlDIJziIA0xYgkp92Wy3mSbsfU/5N5ByagLhAcR8FqvKQ1EXTL0ALU/wHKO54faLruruiMFJgbgI5WWYqCHCA71dF/VKLHozKU1OHmyh0n8AMj//hf4lK3ySCvHOM2uGq5foM/Cqy2s2n1VCDgLKvHRomDapZ9K7Di/JPOJtxjLWaPKtwWkTQGrahksx2eY0cq9iul6nowdG3MaeCIAq43Yjof6a6g4q3R5gEHl7w5dXqNl/VKryCAsNBkb4ezPt2uICSAb1bN 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: Mark Brown writes: > When a new thread is created by a thread with GCS enabled the GCS needs > to be specified along with the regular stack. clone3() has been > extended to support this case, allowing userspace to explicitly request > the size for the GCS to be created, but plain clone() is not extensible > and existing clone3() users will not specify a size. > > For compatibility with these cases and also x86 (which did not initially > implement clone3() support for shadow stacks) if no GCS is specified we > will allocate one thread so when a thread is created which has GCS ~~~~~~ This "thread" seems extraneous in the sentence. Remove it? > enabled allocate one for it. We follow the extensively discussed x86 > implementation and allocate min(RLIMIT_STACK, 4G). Since the GCS only Isn't it min(RLIMIT_STACK/2, 2G)? > stores the call stack and not any variables this should be more than > sufficient for most applications. > > GCSs allocated via this mechanism then it will be freed when the thread > exits. I'm not sure I parsed this sentence correctly. Is it missing an "If" at the beginning? -- Thiago