From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57F323ABDBE for ; Fri, 15 May 2026 09:24:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778837056; cv=none; b=riX/GMnOIqYbPU8QygXHA7H6rzkHTatYVKjJdZjEUC5K6bq5j3eATYlKPqevw3vyfja7+qwZFDf4+ZPwquKbvmSs2MZE5pO0k2QTYZVH/Hup0dwqsI8q6EciAzRwR+AT8EhW8RORxN79/XHE/6GKQGSgp735HvsPTA+mHJ3o+ts= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778837056; c=relaxed/simple; bh=6c5hfgSD5xJa00nFFCK7kaxUQ5uueiePQvAM1Cjtv/s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TrwbgQexmwc2Jd1bJwfCzESzi1sjwkbkJ0bB3JM/CUJf2lHIlAnecI/gyAaw9xmNyZrHQAfejC0o6T1OyDgiE/ySUSwNOVrzZAPZHzKXW8Hh0Uj/hI+W2EknoKBv2sYrv/mLDVa3TCOFIu1PvODje8b54tmu3DBNaYxU07YLFlI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gBNgYpYK; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gBNgYpYK" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-44dd5cb0f81so455761f8f.0 for ; Fri, 15 May 2026 02:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778837054; x=1779441854; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=6c5hfgSD5xJa00nFFCK7kaxUQ5uueiePQvAM1Cjtv/s=; b=gBNgYpYK8JfgIarQaUU8hXGzEPImf3jXrgQIvDIpV7yFarr/MlklO/BVjBdGEqtPUY go18v0xNIm6bSG81w4qLp7RQG09Zs3jvfu5QD5/Po5qGUljZanUP85cCFK9gagRzY+F0 iqXByTyswpM4THR6Pc+nxERrikuD7hxnQaPOZt0W4ejonRHrNH4NSVn7rLaK0Y//K6+7 E4AF8jBDwni1WoaSdwqDJmRSsj8tMZPb3Yc9pUt7m1IESUSCTevp8LST09nF3FBxVsJD iKYIPeWLMiZbDt/Ow4qQAxZ7xyIa0a8+8uT+3Q6hTtRW0RfGumKCfcW2QS9nx+ejoR3h WJCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778837054; x=1779441854; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6c5hfgSD5xJa00nFFCK7kaxUQ5uueiePQvAM1Cjtv/s=; b=ZnQjv8NdwE7kDQpn1pTJ1NIn4Y9KUk5a7vlZcnQ/codBH63GheB+bxn0QEzJw3Ia/1 gfIVPVwSJ1vcDkPlXZYjWQJXurPako583Vl/BeXhD1T/U1dLrRfP2jUkbcgZbXdqjkBY W3YqKNbImO38TJlr+tAJfHc5btfM2DUrBHKjpf+UDdbrgfGg8pYuynPwmP5gym7CIs4X Bd3Sz9Y3TOsV3AtHv9O4oNrHRfRAkqkvfI1VsafxX9ysh1fiTYSc4xoEoUv8K8aQ3xGI 0Vk9Bb22uiiMtUh+G+KSpMFItI7fICp+K6E4iFksZLVa31dsHXbHwzblsZnAZD7lx7EK vLwg== X-Forwarded-Encrypted: i=1; AFNElJ9Cbdk6y2HfDy3bbs51q3tQh5wZjpd4AF1ZxKlQpKz7CnsSI/Vvxo9H9y7CjJG3Pif7TErpCm87FbdD8/0=@vger.kernel.org X-Gm-Message-State: AOJu0Yz3Pd46KLWUDVzP7frnequuCIGkSbPlIORe0/2PABlCS1LCSy4G lgNS9OgCaTeZenxfDJst6kXYH3I4SLVEi+gbaS8IPRiRR1F5Kr+uXFm9 X-Gm-Gg: Acq92OGmawK7SNyLhYWUOO26Qx3zRu1V9zA4GQgaRkkK6Y9Wods6p/i2UkNIn5o2Uf+ KYWN4V/F6/iHcpuPbaYvzZJlHpFnxT+IwWXMs3K7KkDR+NfstoLLaSpwCG1iu7v7SzrSy1XXtZa pThi9cIrR/GY3W5Nis0p6y4CewUwU8bkpMsp512XTXsT+Pwm6cbF8tZKIlxg/m9Zzl4VIH1JW6A Q2JSyeBy89BluRU0216prJsqKT04u/Hhfd5Or583VToFgvnjMM6ds4e96HdpkbggRUZci3QpzyA Z9d6I/3KrD8tXWa7FQKGJyoKcYtYV7DmMA6CpCibt9zEOocz8tceUydO3ap+wUCbryOKYLj6+8u ZcJj8Tvnmylc+VR21Ww/ZA+I5G+2cGXE/xsP7rVHEC83DYHEYavW453jA4013oSy+HYrH5NeYcI JSHEajA6nUJnhD/vfn4Y+KUzjnycMN9X1BLkqNOtxVmtlToGW4r8+EoUhyyplF X-Received: by 2002:a05:6000:290f:b0:43e:a75e:352 with SMTP id ffacd0b85a97d-45e5b73b1d5mr4833404f8f.4.1778837053558; Fri, 15 May 2026 02:24:13 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9e768acesm13910437f8f.7.2026.05.15.02.24.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 02:24:13 -0700 (PDT) Date: Fri, 15 May 2026 10:24:11 +0100 From: David Laight To: Zong Li Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, debug@rivosinc.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB Message-ID: <20260515102411.4d3e868a@pumpkin> In-Reply-To: References: <20260514075036.1432352-1-zong.li@sifive.com> <20260514095605.2c7d8761@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 15 May 2026 11:42:45 +0800 Zong Li wrote: > On Thu, May 14, 2026 at 4:56=E2=80=AFPM David Laight .. > > I also don't understand the rational for just /2 and the 2G upper limit. > > You need 512 nested function calls to even use 4k. > > That would have to be quite deep recursion. =20 >=20 > During the discussions about the ARM GCS v3 series, community pointed > out that a 4G shadow stack might be too large. This size is hard to > support in memory-constrained environments like Android. However, the > size cannot be too small either, or we might face stack overflow > issues. At that time, a perfect size was not decided. It is only VA not real memory so shouldn't make much difference to memory use (except for nommu where the actual memory has to be allocated). But 32bit programs with lots of threads can run out of VA. Increasing the stack VA size by 50% might even give problems for 64bit programs - if they are already reducing the thread stack size avoid running out of VA. I've not checked, but pthread_attr_setstacksize() sets a limit for the thread stack size (which would otherwise default so rlimit(STACK)). I don't believe it should update the rlimit value itself. In which case you are using the wrong size. But for a thread with a very reduced stack (say 128k) you probably only need 1 page of shadow stack, any more could easily lead to running out of VA. -- David