From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 EEC3C3E2AD5 for ; Fri, 15 May 2026 19:16:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778872581; cv=none; b=JsCvBzCAXf565h1f7Xbu3RrHyznNhNTH9J1fCHHAWug2+j0tjlE+IKZzIosOcoe1J7Y3LqG4BZZs6qc4xoUp+NYNuhyWZlleFpas1XCQq9aU66hSrY4XsSHXU6LfZosDCJvD6IgwUmNe0SIpJV1tcjO0FalpirdvUk40IROPzCQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778872581; c=relaxed/simple; bh=qFSsQZtL4zku2v+LL7cZRNdevKnxrmVTACf2sJxsL7w=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fax9hmq+D6VM6YB+UooBJJQMAZqLvhrFAgKfXnnVxyqt2p80CuzjjserIqmXaTwkDEXZJoOtblVn5Ai1t5JCSKTIP5CkeidcWAdXAK/2O9MKd92Z6LMUOaJ7CyN2OmT4d0f+RTr2PGQ0XodvH+RKMAq9rqFmmHKxgV6/FW1AZAQ= 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=SiroVa/Y; arc=none smtp.client-ip=209.85.128.51 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="SiroVa/Y" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-48909558b3aso1612155e9.0 for ; Fri, 15 May 2026 12:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778872578; x=1779477378; 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=3LnYbJwS1H257uWrNX2t9Fc9WjDdmWNsOdHa8UwPeew=; b=SiroVa/YAT9aKMrPPs4LD09u73AN5yDmJDlx1d6g5hA8UD6H+NuTfOwOei6tBzGiE1 IhIMWcRG64bf06/1fIJCFKkFP8wDMYh9Gd/4FlIuFlWZtAD4hqM1fUddlOnFWMr7eO5Q adbLqGov+sY18Wu+D92hcRT/5Pl9VUYBU+d6LS4GBlHgLhKfILYRrJ1J2K0OCZSS3dAe bw0vN+N13yDoURI9R39NvfnrOK9p+3zO9eFfe46sOefzlWRSn7vn2ynSXkQWkOqzZRSx TvBooKYTIabSURA6E9MwjJSac6wYHgIkt3PUTcDHvwFclT4OP/2RFbVPgfzotZONgTH4 Clww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778872578; x=1779477378; 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=3LnYbJwS1H257uWrNX2t9Fc9WjDdmWNsOdHa8UwPeew=; b=dDMcDWQCSGDtziukmtKEWBZKmHd1ZskLks6Z4KdrA8fRp4xzgplWKFdnW/MbiTTyY/ /vo3WaBa6Pt2yDlxBPjyMZ5kYwOcBHg0jvkCM6aGDYTwruW4Dq74B1uxK1FFKPDnxz+0 0uc7sOzYT/S89QrjDV2oQ0bNA1d7SG6jydq66KYz+D895CM/YwXoivf1ZvSNrP2nMmsk yA5ovcWQcEM2tWPt5pl2Vx3PwfQ8kILSTz1+yCTSv4u3M3nADnRQvN55ahWvbgPMu+tw 6bB3ogNmAtPrwkwbdsupGIY/9c+Npj3azjnWfUyx6B/Oy93uByFY+5NmzWkbd4HKBefM H+2w== X-Forwarded-Encrypted: i=1; AFNElJ9Tl/bAj0Tuf29NgyB3oInIYv2cmVfXdltiyKxbqHr0q1XrHMLcJSO82SAuH5Ry6/hPyUMFpWYT1ufSFjo=@vger.kernel.org X-Gm-Message-State: AOJu0Yz9604QrZ6pIv60PsugRQRKwIgLy52+c8l4bmqk8kKNSTRV0cnm pE6HW/+m3VISzpUOA1zhUe5oiz4Pii4eqlh3BSb5roVUakwycrjZg4E8 X-Gm-Gg: Acq92OEKCg9vMDDBO++j3URefEG+gEXrigsIJvMq4yvfHpm78n73Lnjed0zAtMtXxi2 /KC052DMgSvTdYu8+374TiNN+nHHJfMsRvasAXQO5oarbhGZW7qJ3L4kEWRdjJWmIZfWOY/ONNr jv1tzBK79H7Aj9d/RndrHOfPrLEceRmBNm55wBzaWqRKGiilflit/dMDnfWbBC/BZhpT+3E6M0Q N+NNkL80nnh2swe3h+ClMEaWj1di+KtDIn/cAxwWF4ewEukknV/QQMtLeOMKoimGAz5+G+gQcp1 b9c1gSFMktbLms10/QMlDxqWN3cWOVOnhvZLRAa/s6Dnp9lVvhArvsfPSzyGLl9HBdbKnA1y4TU a3cGbQJufuDhX+7Mvsoj26yHwgYYVRyz+j64UWDKnqaSMzyFTrh7ycLsI9VLJIHI4RkeB04Ozel jcF+D4GTxDiMdIVyla8wnrI9RtMZw3S7ZjK+mAXZ9MLIs6/rqvxZfz0Tt792/i41hTkQ9KP34= X-Received: by 2002:a05:600c:c087:b0:48d:c0a:3813 with SMTP id 5b1f17b1804b1-48fe60de6a7mr63536195e9.3.1778872578055; Fri, 15 May 2026 12:16:18 -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 5b1f17b1804b1-48febe585absm20016505e9.19.2026.05.15.12.16.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 12:16:17 -0700 (PDT) Date: Fri, 15 May 2026 20:16:13 +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: <20260515201613.243ea49b@pumpkin> In-Reply-To: References: <20260514075036.1432352-1-zong.li@sifive.com> <20260514095605.2c7d8761@pumpkin> <20260515102411.4d3e868a@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 22:29:05 +0800 Zong Li wrote: > On Fri, May 15, 2026 at 5:24=E2=80=AFPM David Laight > wrote: > > > > On Fri, 15 May 2026 11:42:45 +0800 > > Zong Li wrote: > > =20 > > > On Thu, May 14, 2026 at 4:56=E2=80=AFPM David Laight =20 > > .. =20 > > > > I also don't understand the rational for just /2 and the 2G upper l= imit. > > > > You need 512 nested function calls to even use 4k. > > > > That would have to be quite deep recursion. =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. =20 > > > > It is only VA not real memory so shouldn't make much difference to memo= ry > > use (except for nommu where the actual memory has to be allocated). > > =20 >=20 > You raise a valid point that shadow stacks are primarily a VA > allocation. However, in Linux, the memory overcommit mechanism creates > a practical link between VA allocation and physical memory capacity. > As I mentioned in the commit message, memory allocation will fail when > the overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER. >=20 > In __vm_enough_memory: > if (pages > totalram_pages() + total_swap_pages) > goto error; >=20 > Many page requests for VA will fail if the requested size exceeds the > system's total RAM plus Swap. On memory-constrained systems, > allocating a massive 4GB shadow stack per thread would immediately > trigger this error. But reducing the size by half makes little difference. You'd need a much bigger reduction to make any real difference. -- David >=20 > > 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 =20 >=20