From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 93F6F3858C1F; Sun,  6 Nov 2022 20:12:36 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93F6F3858C1F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1667765556;
	bh=+nOTYjd/NfB3JJ/AuQgEWpS9d5TtbiGgdEKnYZtkYAY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=HSUDenmIL2RGPcv2J5BqWYCVtodPNDBaaUR1qN4zCi2KXDl2omR/hOSogmNeS+CoO
	 49UbsfLlt338uKo1NcqS6Fgm/6aCg+OJ4b9/oAt4pDY8fFVuzIFfftPnqc0v/1Soll
	 UaJWT35a4np+79aWxZusvXd7tiQ5ypRdMOQDjZ+k=
From: "i at maskray dot me" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/11787] Program with large TLS segments fail.
Date: Sun, 06 Nov 2022 20:12:35 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.12
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: i at maskray dot me
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: review+ security-
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-11787-131-0fmy5WgW7e@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-11787-131@http.sourceware.org/bugzilla/>
References: <bug-11787-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <glibc-bugs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D11787

--- Comment #50 from Fangrui Song <i at maskray dot me> ---
PTHREAD_STACK_MIN/RLIMIT_STACK/minstack computation is now in
sysdeps/nptl/pthread_early_init.h . I think there is not much change from 2=
012.


I agree that the current behavior is not ideal. musl has a heuristic to add=
ress
the problem
(https://git.musl-libc.org/cgit/musl/commit/?id=3Dd5142642b8e6c45449158efdb=
8f8e87af4dafde8):

> the new strategy pthread_create now uses is to only put TLS on the
> application-provided stack if TLS is smaller than 1/8 of the stack
> size or 2k, whichever is smaller. this ensures that the application
> always has "close enough" to what it requested, and the threshold is
> chosen heuristically to make sure "sane" amounts of TLS still end up
> in the application-provided stack.
>=20
> if TLS does not fit the above criteria, pthread_create uses mmap to
> obtain space for TLS, but still uses the application-provided stack
> for actual call frame stack. this is to avoid wasting memory, and for
> the sake of supporting ugly hacks like garbage collection based on
> assumptions that the implementation will use the provided stack range.

Here is a one-liner for people to investigate large p_memsz(PT_TLS)

   for i in /usr/bin/*(.) /usr/lib/x86_64-linux-gnu/*; do readelf -Wl $i NN=
 |
awk '$1=3D=3D"TLS" && strtonum($6) > 64 {printf "%d\t", strtonum($6); exit(=
1)}' ||
echo $i; done

(Adjust paths and `> 64` as needed.)=20

It seems that chrome has smaller PT_TLS now. On my machine there are DSOs w=
ith
large p_memsz(PT_TLS):

libtsan.so.2.0.0 has a 785760 byte p_memsz(PT_TLS) due to a large vector cl=
ock
(TSAN runtime v3 has a much smaller one).
liblsan.so.0.0.0 (56240)
libglog.so.0.6.0 (30457)
libmetis.so.5.1.0 (28920)
...

--=20
You are receiving this mail because:
You are on the CC list for the bug.=