From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2EF5D1F45E for ; Thu, 13 Feb 2020 16:39:12 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:cc:subject:to:references:from:message-id:date :in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=default; b=CGZGsZm2zZkG6EiS516dWU+SuHSgK 3Q4/SZVlqNGOVJmpX5urmd4Fee80u/WLrFdcEARhA9Ds7AQeFU7PUTtiJy63BygN bLsS0KLLmP5R0BwpTnRXkCcN5pPAlF2iVV3d+pwzNwJ+wGtQ0XCgwewvP2HjIw3I Kf6k37sHJHKZqA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:cc:subject:to:references:from:message-id:date :in-reply-to:content-type:content-transfer-encoding :mime-version; s=default; bh=HW5bnL+24FNwRXhTCqb8F2Hm3x8=; b=RHi PvTVt9D0LgWjp2pDE7OGVf3CqVJi9TXxldeZ/uwWeyME8YD8Lj3zCFWexPdKTDD6 xhkaWCVFNhBf4Be360L81PTKj52lSvjbKIzEIobVrJ3bVsyPJBC+XFaKga8aWzZn 6ThjLIpeJ0YIEANtCZbRhlWDMse+rTrytiCwvKrE= Received: (qmail 80480 invoked by alias); 13 Feb 2020 16:39:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 80471 invoked by uid 89); 13 Feb 2020 16:39:08 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y69+6fjFZ8OUNySXtHLXrX0g+mOGzfW3J6S8C6PXqaA=; b=ISjnKG/T6WBpoIp9B6T/iDKX8j3SbmNRZlYD+3piEkk/gYHDBU+5DaaORyeja6PbTaTM4amhb88zp35rcf8NNA8oEc7QwArJ1mZaMOgQsoM7Qrw+Db2hYda6tpl49XoUHU1sMHBUC+SSaxvvmWgpcivw2IkRdmS/hqLaMPkOU/g= Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; X-CheckRecipientChecked: true X-CR-MTA-CID: e61ca03a940e811e X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hqzIyO+dgFNnG4X0MjTME6KJPw2jDDLc0Z9qApyFaQmrXjzL6l9Kyl8gW83cO7wx9sV8/Er1utZMp4Ro02DRztRxIu24uzEQtfXW4EaVF83GmvdmZOdOmPymD4TGZeDaPkELZdXqhY7QTtlacxL/TLw16CUfJeI5COr1Q8rk6hC4UEmLuM8wSQ3ns5lnsGvatI380U+jYF2+8p2PjazUoBBg1hIfyldUUFTwGpTSQMI0RQsNshMQnKVdWakw272DsN06N8zBiRxhGlhgpiPbFqSFIX/c3TdE7kusLEJDODQYpdU5VVA/NF7dXrZxvWpA0G9YP+LLXxvndjXlsNfoog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y69+6fjFZ8OUNySXtHLXrX0g+mOGzfW3J6S8C6PXqaA=; b=SXQTMSUArnF2e0dSVYTDT5jTQ1czPIzakJgeErIdgIJv53J32J6AolbX/qXQwP3sjMFetCc9FBMF2TJI7sTV6yXjluTcAvcZ4sssx2S8f7CY2oOXjds58zJbdZXfL3cyc1Q4rKXqcaZHcYRyFBnNNsLPDoIgQJBbEDob8gkWFDi+TNKt3RX5UGt4d10vYutXynXHHBzwN+NFeH3OrGj+CrGGYlUX02mk5DS2YMGCQjeAVaqL+BL5IPrV+BZxHnkzzXQvkYW1okH6K79DkmnT+HHZj+/ddF04JzAB4rVx2H/yH3IrPr7d9W9czCUC5ljq5zpFSP9tlH2tTOsckbjxrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y69+6fjFZ8OUNySXtHLXrX0g+mOGzfW3J6S8C6PXqaA=; b=ISjnKG/T6WBpoIp9B6T/iDKX8j3SbmNRZlYD+3piEkk/gYHDBU+5DaaORyeja6PbTaTM4amhb88zp35rcf8NNA8oEc7QwArJ1mZaMOgQsoM7Qrw+Db2hYda6tpl49XoUHU1sMHBUC+SSaxvvmWgpcivw2IkRdmS/hqLaMPkOU/g= Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; Cc: nd@arm.com, GNU C Library Subject: Re: [PATCH] Reserve static TLS for dynamically loaded initial-exec TLS only [BZ #25051] To: Florian Weimer References: <44eaccc2-f760-88c0-989a-e413e328b051@arm.com> <87lfqjv56h.fsf@oldenburg2.str.redhat.com> <5533fb62-c336-45b3-71ec-30c5e7d7ac4c@arm.com> From: Szabolcs Nagy Openpgp: preference=signencrypt Message-ID: Date: Thu, 13 Feb 2020 16:38:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 In-Reply-To: <5533fb62-c336-45b3-71ec-30c5e7d7ac4c@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 x-checkrecipientrouted: true X-MS-Oob-TLC-OOBClassifiers: OLM:8273;OLM:8273; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(346002)(136003)(366004)(376002)(39860400002)(396003)(189003)(199004)(86362001)(81166006)(53546011)(81156014)(5660300002)(4326008)(8676002)(6486002)(44832011)(31696002)(31686004)(186003)(16526019)(26005)(478600001)(66946007)(956004)(2616005)(6916009)(316002)(52116002)(66476007)(2906002)(16576012)(66556008)(36756003)(8936002);DIR:OUT;SFP:1101;SCL:1;SRVR:DB7PR08MB3307;H:DB7PR08MB3292.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: fo0BYpnRRJWHRpfydd5hqrmcgv2G6iqDT++M39vfy2m2AmZH5xPt6xD2/yZ8EpvN+qzYA+6SJ+sOyr9itZwhjbDYYG1mCIKKTBSyG/u1PZnd//uxvk6FCAe1dsX8wOVRnZkU7mnrpzrNheoRH8GQXzuAv6OT6tunHaxKP6rJFt3OmcAdInsb4+nfivnrDVjNyCXQwFU0NEreCkJyfP0jVhTC5nb+w/OXRM40P2QjVCTRDv5wAPIXhCOx4ARp3c+T8T/8Pqk4t86i6LpBYhYnzquRgsfreV0uMOTk7cYbR0WVkhJ2x5NAwKtIdJCaC92E5O00l/xJFfCEXTjRKyxDBMdP6ij7HxRVN5+UD13xzWw3wNlaOHgDqydsF2npjWhpeGJyzypypRB3wQyy8yduSADRoQL/nxjdsVbdwoqAATm7G/lIpfsv5zEE8USM8g03 X-MS-Exchange-AntiSpam-MessageData: hN8nPGsWFGLF5w7d58rg4b/Ob5onaksnl72n/e5vFzty5wR64WRXqTnbY4uPWSlf5rEsouyXw8nHfmXi5D7axpEazmNBbFFya40U2u0cd27qVWxwKMBR/6ATPu9LcUOEZfFFxKqfkf6rDGMaPnQCKQ== X-MS-Exchange-Transport-Forked: True Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: c1d432e7-940f-43aa-1f66-08d7b0a336e9 On 07/01/2020 12:50, Szabolcs Nagy wrote: > On 07/01/2020 12:09, Florian Weimer wrote: >> * Szabolcs Nagy: >> >>> This patch reserves 128 bytes of the surplus TLS that is not used >>> opportunistically. TLS_STATIC_SURPLUS is currently 1664, so this still >>> allows 1536 bytes for opportunistic use. A new test is added to verify >>> this ABI contract: dynamic loading of libraries with initial-exec TLS >>> is supported up to 128 bytes in total on all targets. This should be >>> enough for system libraries such as libgomp. >> >> I'm not sure if it's enough for loading another libc.so.6 via dlmopen. >> Have you tested this, by chance? > > i haven't tested, but that wont work reliably with > this patch. > > libc.so on aarch64 has 144 byte TLS (8byte alignmed), > so the reserved 128byte surplus TLS is not enough > (can be increased to 144 though). > > however if a lib with ie TLS is loaded before the static > TLS runs out then that works: the 128byte reserve will be > kept available until the 'opportunistic' part of TLS runs > out and then the reserve can only be used for ie TLS. > (so early dlmopen of libc.so.6 and later dlopen of libgomp > works) i plan to work on this, but elf/dl-tls.c has /* Amount of excess space to allocate in the static TLS area to allow dynamic loading of modules defining IE-model TLS data. */ #define TLS_STATIC_SURPLUS 64 + DL_NNS * 100 with DL_NNS == 16 this gives 1664 byte surplus tls (+4 byte extra in some cases because of alignment holes), but ideally it should be 15 * 144 + // 2160 bytes for dlmopen of libc.so.6 16 * 128 + // 2048 bytes for dlopen/dlmopen of libgomp 16 * 8 // 128 bytes for dlopen/dlmopen of libGL* ? = 4336 bytes. (i think if rseq is committed libc tls might increase to 192 bytes, because of the 32 byte alignment of __rseq_abi, with that it's 5056 bytes.) my understanding is that namespaces always need at least surplus tls for libc (except for the first namespace) so supporting DL_NNS == 16 would need 2160 bytes at least (the current surplus only allows 12 namespaces at most). i think either the supported namespaces should be reduced (is that an option?) or the surplus tls size increased. we also need a policy when non-ie tls libs or ie tls libs other than libc/libgomp/libGL may use the surplus tls. example solution: #define DL_NNS 16 #define DL_NNS_SUPPORTED 4 #define LIBC_TLS 200 #define IE_LIB_TLS 144 #define NON_IE_LIB_TLS 1000 #define TLS_STATIC_SURPLUS \ (DL_NNS_SUPPORTED - 1) * LIBC_TLS /* 600 bytes. */ \ + DL_NNS_SUPPORTED * IE_LIB_TLS /* 576 bytes. */ \ + NON_IE_LIB_TLS /* = 2176 bytes surplus tls. */ opportunistic tls use for non-ie tls libs is only allowed up to 1000 bytes and 4 namespaces can be supported at all times, beyond that dlmopen may not work (opportunistic tls use is target dependent so the dlmopen limit will be so too). does this make sense?