Message ID | 8c6dae9ee45f9af51ce70cb8422582096dbf7ffc.1613390045.git.szabolcs.nagy@arm.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Adhemerval Zanella Netto |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CC1EA3951894; Mon, 15 Feb 2021 12:02:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC1EA3951894 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1613390550; bh=1SBxDdn5sEz1vzpy6+7YsvHR0QbPIBAAXPBMadvxq70=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=vQr7frFvicc+RJI9LNiPgZsNGH8ylsgOZHoRGS6FBQlUAC4LJysck24I9+D0itHjl sp2snizBoVUlN4PdCRgsgi9XSni/bBjRjJOO9NwFoSIiO6pPJvIkHtkjqPAyWYk0U8 R7q0aL+Na87bfrd58fPhUnvHO/4vLcAsIWGL+Kq4= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70050.outbound.protection.outlook.com [40.107.7.50]) by sourceware.org (Postfix) with ESMTPS id 23C4839518BE for <libc-alpha@sourceware.org>; Mon, 15 Feb 2021 12:02:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 23C4839518BE Received: from AM6P194CA0019.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:90::32) by DBBPR08MB6267.eurprd08.prod.outlook.com (2603:10a6:10:20d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Mon, 15 Feb 2021 12:02:25 +0000 Received: from VE1EUR03FT006.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:90:cafe::4b) by AM6P194CA0019.outlook.office365.com (2603:10a6:209:90::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Mon, 15 Feb 2021 12:02:25 +0000 X-MS-Exchange-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=pass 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; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT006.mail.protection.outlook.com (10.152.18.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Mon, 15 Feb 2021 12:02:24 +0000 Received: ("Tessian outbound f362b81824dc:v71"); Mon, 15 Feb 2021 12:02:23 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 50d802a96d913f64 X-CR-MTA-TID: 64aa7808 Received: from e1a662b4de8c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F8376CA0-3E12-4FAE-9BF7-9DD7765C1388.1; Mon, 15 Feb 2021 12:02:18 +0000 Received: from FRA01-MR2-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e1a662b4de8c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 15 Feb 2021 12:02:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FDH5Fx4juWNSGCTpq9qtXb873pEJ/KI35mAYMnQetPp3VURGTjDJB3XRQJK556gEH+hkqG3MKrz5KvQLpV7L3FRnVJ+YJlgii7v5jbfvgnBF8nY9wY/O51Hxipv1ZbxgEh1zxEbcclXZkb8YrcK7ijCb4PV2kdimDDkmoE4M3aY3MVkIOqqJO2TfgNgi0D224iNDBx8bcUAxZdlsbI3DrDGSYhM2FzbF6BmFZZmWsw/XT5miKmqxnipUu3PGrtcVCkOom9IosenBioak63KAjm48SPy/nriY8K/1Mq27bAhSEavBtC63USRr7bzNeyYFd+XQLHW4+KrjTrgfzsUXXA== 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=1SBxDdn5sEz1vzpy6+7YsvHR0QbPIBAAXPBMadvxq70=; b=nIj0zYp5EVjnRlzfHZA7gorIMB+ZaLUQry3ucrkqYZN/oEULt1JYUiwGB4qsytD7VNtixtJ+veLaydtPpDxQXCKwTXNHoYI4cQR3d8e6+Xrnd+KAbP2FSOCWEdAm02t615mPDD5EoOJQ8EMzymPLKpbFoHrmVnPQkbrAoUQiFBj+yLMPlejh+h3WdGl8qp54Yxbp/laM7ma7PavSx7bEv4ICayFfUbrlhybHLEKj5FvmW3gJwCUDLdZ397gOErLPeumpVuWoeRajS9PPhBEIPFI05V6TeVopd/7J5zxDd21ObyOss44FQA5x3IemGYSIDexSf+ydsRF9XejVAAXWMw== 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 Authentication-Results-Original: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PR2PR08MB4809.eurprd08.prod.outlook.com (2603:10a6:101:1a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27; Mon, 15 Feb 2021 12:02:17 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::60f0:3773:69b8:e336]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::60f0:3773:69b8:e336%2]) with mapi id 15.20.3846.042; Mon, 15 Feb 2021 12:02:17 +0000 To: libc-alpha@sourceware.org Subject: [PATCH 11/15] x86_64: Avoid lazy relocation of tlsdesc [BZ #27137] Date: Mon, 15 Feb 2021 12:02:05 +0000 Message-Id: <8c6dae9ee45f9af51ce70cb8422582096dbf7ffc.1613390045.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1613390045.git.szabolcs.nagy@arm.com> References: <cover.1613390045.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-Originating-IP: [217.140.106.49] X-ClientProxiedBy: SN7PR04CA0116.namprd04.prod.outlook.com (2603:10b6:806:122::31) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.49) by SN7PR04CA0116.namprd04.prod.outlook.com (2603:10b6:806:122::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27 via Frontend Transport; Mon, 15 Feb 2021 12:02:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1f5c6fc2-f7e7-4a7b-ccff-08d8d1a98e7d X-MS-TrafficTypeDiagnostic: PR2PR08MB4809:|DBBPR08MB6267: X-Microsoft-Antispam-PRVS: <DBBPR08MB6267B4714AE88F5CC792CDF9ED889@DBBPR08MB6267.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:923;OLM:923; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: FCC3ZXVRTs7V9XRm2op0RzApLrAtDn1bMDcRRRN7Ja0PE9Ib4535J2oIAd+s3nPSdSDBCQ45VvVmiY781LburRlMpxH/q5jIG5/SI8wBugeSjs2y/DXHleZ6nFzn8egcbisK1ygYUmbOINIk1Q1fD0x65bSws7kmMg4B5GGucxGHHnnYI5wcf00fjA8dMqlEjLfb3Zg2H4+3ekfb05i77j4Bi6QWqoVB1bH+edGHxWaWKGqqFXI1RVInTekBKSXDypJKQ1esVqFb9rogd3dEkuisofJB/o9BPhsB8FeUoE/ihp3ao84ep2/QJyFNkrbrmW3UyMSYMhRirmffrkDqry0nLmf+XuL7dUwGCQPK+A0e3hsyv9mez5X9foyocaUBdPHuLzBRna5OJ/sDJUgu1YChKwx/VhVVCtjvVgZhRfmJ8RokCS1pnCXAnG79eP+YimOt3Wvg83VnNeCPayMcABNul3MVysrmyjrI6ks+ay58mzmjE3rkk0o9n5ndrmpYqy4ZuTFuXYQS92AS0AMTe/Ua8Nf434WVAsJcr9/CcZr6USy7h56ZW2ibKRtWHEHGnxTngZMSo8+k0MtLFOXiMg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR08MB6320.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(136003)(376002)(366004)(346002)(44832011)(52116002)(26005)(186003)(83380400001)(5660300002)(316002)(16526019)(956004)(36756003)(6506007)(6916009)(2616005)(66556008)(8936002)(66946007)(6486002)(6512007)(8676002)(478600001)(66476007)(69590400012)(6666004)(2906002)(86362001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Sx44UcabFLH3gpkLAop9UuGh6AnjOI1sAmKcrEG4RySYQVZNIPTN09x6rSHwJJNH5iovdOqpXQUF6j/VgLXMNAw+VCnJpWv+42z2w148Ckgr2Cn8J0AjHSmvHGYfnlbCvPi66M3+2ISts5jz03xtHlim+avOhuD5sXqeT9bwpDe/A3ytsJCrQ7wJcwL6RPIZc/p6xyCAMI2nrFBaDZen8GK8escjOih0bPrvOYEUqTKfWalXgCIejQ2YUVRGKYu/TDLfl6fzR4zYxHRKm5EEb82Jgl/+1p8cTPU1LKeYdILOGG4RFrY/MSJFxcDjTMqrsKb8ouo/h8UQSzfo7i984fpvAH60HxfbrMjeF0E+CbFnYp/c/NTF75k+05CkQWanCASpt33Gx++l6IF5qJ32TwT/bjaWtWkB8DvWpGaKaXwFQ1SygqlW1iT5JqdA13q+Gv0aLNlSbz6qLZnhB5aiQIPExh2wVyYWK+r1glqvMc9Wpj53s3WHOkDqAuChjxcyIkzJZ1iywML+U0q7RN56mMbM04v8S3p84r9KCNTAHKcQcWQdqqS9+RG5p2g3ua4T8ld56+6UmpaetIT/+tA4vuS22100UtYIq2NyaQbqDeD4XbsUQQuF/BDaXUDVbn3I6xtSiMnbo+F7tqCQ+vlTSkoibYA/pqgqWRTcwTdV9e5hXgDkQN28TOMs3HdNd2OLhoBifvRZsEoiE4H5EAR+QPsuG2tnK4i7g99QxelpSeidtu2b78EPh5hpAPwmB0VsDYCpUADdSghUqWv1aAiqDLqWHmXvIP+DTMGsZ/iKZbjNB/dFDSzM5mrxZgZQA//K1aEQNHcDcaLTFeSpaF4AuXuVtIEcwEf9bbgtHqoD+abPhfANhWkkedkapSEtmS4eig5GvsDPle8wSC8oS4Vkrm+RDlxnyTFYhfl7aKdLWQnOaNBLkmT8DnKVJaCaOjNeIuNHKZ3oHHe97ip2l6EyV88Fk5VwyRWH5f/A/8fnYHYfMSrRETxJxapE0kdfgHXmMc/OM3+5izGYXZiiYidmdX0HQlOtnJmtYPCDhPuSAUYXKU89Bjx0NXfTzyqDY5pCEFoHideYCnd0aYW2gzvcqRYYmSdv3oOAg+Mc/zp7Yyv0ZvUCGDFHeUHWWY/ZCeu/IKbr/Go2OQrd2I4QqQ4P9I/pzjaCgBqFsuZRNVfYJGp2gATMaAHnUVADX/U8IRsoX7vMedpd14IQ90TEg79dxbvuD+OE2VkUoj1RIx9S1J1sP/vg7rggO4Bipl9HZWH8Px5zvPRCtAaNX/CV2uyEtI0AQ1tnccO8KG3rjqq32Z82Mm8jVJ5b+CyYKLXtsjlR X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4809 Original-Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none; sourceware.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT006.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 61496d51-067b-4730-1ffe-08d8d1a98a04 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Nl7nG12ntwVav5VOoN1fxsvRh0VqP71TdKp83GKYeXWfyaxyQ5+YhwIvdT/rE+YtRF/8O5cEAmFbZRYVmzD8kUtf1/6HIQIoJoqKXVDMuFVsj4WVRFIlAJHmT+sbye+PRTajYmhVO5b7SduErCHJEIhP3dGgmjXRZsqv0lS+aW6qRbKswMu8Lz3++YgKEXEZ13bD5Yj+Tr7C9j+V8k2y/PKw20K+4Kc5zZpqvxqh7KGVGwfWDqcjyVhbPTuux4E3IW5cneZqYLm8Fy3bnN2jZm9RuvUCywo7jMInycjXtdTMgXcZCYvOtNuXh6bJL2NrbmJ1KCd2ISugEp93oACm/ny2t014jwoVQYiVGUVcloFT4cecOSqz8gYpjaV+L8luFHBPfFJuu2hQp7xE8yZ1uFnS0UqjJNyU45Kg8OEMN1PQ0Oq8P3RUACUN32omwi6uK0K3Nmbbfd7nKiaacALrtRM8iAJy0e0gFd8f2DtktIIB8AtKgwGQd4yGtSk/jDJNiuQYuy+dAZGXjghOhgTXjFH+NIETeEtRI7vRW/8AtUm0sqfseTKN3+ftpZBQnJBPkx9pDJn9oaHgTitv6y0cFM1QhD4WsOy2xVq6FFKH6NxE35At76SOtLpj31JXkFe5yEdSeBUOdKpfETOibOkLIOn+XWp76FulNy3ydTkAtM1K49ZdbcvcINVkFxaS5BHn X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(39850400004)(136003)(36840700001)(46966006)(69590400012)(478600001)(82740400003)(47076005)(70586007)(6666004)(6512007)(81166007)(36860700001)(70206006)(356005)(36756003)(2616005)(8676002)(86362001)(2906002)(956004)(44832011)(6486002)(83380400001)(186003)(316002)(82310400003)(5660300002)(8936002)(336012)(6916009)(6506007)(26005)(16526019); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2021 12:02:24.1913 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1f5c6fc2-f7e7-4a7b-ccff-08d8d1a98e7d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT006.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6267 X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Szabolcs Nagy <szabolcs.nagy@arm.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
Dynamic TLS related data race fixes
|
|
Commit Message
Szabolcs Nagy
Feb. 15, 2021, 12:02 p.m. UTC
Lazy tlsdesc relocation is racy because the static tls optimization and tlsdesc management operations are done without holding the dlopen lock. This similar to the commit b7cf203b5c17dd6d9878537d41e0c7cc3d270a67 for aarch64, but it fixes a different race: bug 27137. --- sysdeps/x86_64/dl-machine.h | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
Comments
Don’t you also need to modify elf_machine_runtime_setup It also has a reference to _dl_tlsdesc_resolve_rela that becomes undefined when you try to compile with your patchset including patch 13 where you remove the code. To make a test build I just commented it out but I think that this patch should remove that if statement as well. diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h index 9a876a371e..2b1b36a739 100644 --- a/sysdeps/x86_64/dl-machine.h +++ b/sysdeps/x86_64/dl-machine.h @@ -127,9 +127,11 @@ elf_machine_runtime_setup (struct link_map *l, int lazy, int profile) } } - if (l->l_info[ADDRIDX (DT_TLSDESC_GOT)] && lazy) - *(ElfW(Addr)*)(D_PTR (l, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + l->l_addr) - = (ElfW(Addr)) &_dl_tlsdesc_resolve_rela; + /* Lazy binding of TLSDESC relocations is no longer done so this logic + won't apply */ + /* if (l->l_info[ADDRIDX (DT_TLSDESC_GOT)] && lazy) */ + /* *(ElfW(Addr)*)(D_PTR (l, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + l->l_addr) */ + /* = (ElfW(Addr)) &_dl_tlsdesc_resolve_rela; */ return lazy; } > On Feb 15, 2021, at 4:02 AM, Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> wrote: > > Lazy tlsdesc relocation is racy because the static tls optimization and > tlsdesc management operations are done without holding the dlopen lock. > > This similar to the commit b7cf203b5c17dd6d9878537d41e0c7cc3d270a67 > for aarch64, but it fixes a different race: bug 27137. > --- > sysdeps/x86_64/dl-machine.h | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > > diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h > index 103eee6c3f..9a876a371e 100644 > --- a/sysdeps/x86_64/dl-machine.h > +++ b/sysdeps/x86_64/dl-machine.h > @@ -570,12 +570,21 @@ elf_machine_lazy_rel (struct link_map *map, > } > else if (__glibc_likely (r_type == R_X86_64_TLSDESC)) > { > - struct tlsdesc volatile * __attribute__((__unused__)) td = > - (struct tlsdesc volatile *)reloc_addr; > + const Elf_Symndx symndx = ELFW (R_SYM) (reloc->r_info); > + const ElfW (Sym) *symtab = (const void *)D_PTR (map, l_info[DT_SYMTAB]); > + const ElfW (Sym) *sym = &symtab[symndx]; > + const struct r_found_version *version = NULL; > > - td->arg = (void*)reloc; > - td->entry = (void*)(D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_PLT)]) > - + map->l_addr); > + if (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) > + { > + const ElfW (Half) *vernum = > + (const void *)D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); > + version = &map->l_versions[vernum[symndx] & 0x7fff]; > + } > + > + /* Always initialize TLS descriptors completely at load time, in > + case static TLS is allocated for it that requires locking. */ > + elf_machine_rela (map, reloc, sym, version, reloc_addr, skip_ifunc); > } > else if (__glibc_unlikely (r_type == R_X86_64_IRELATIVE)) > { > -- > 2.17.1 >
The 04/08/2021 17:14, Ben Woodard wrote: > Don’t you also need to modify elf_machine_runtime_setup It also has a reference to _dl_tlsdesc_resolve_rela that becomes undefined when you try to compile with your patchset including patch 13 where you remove the code. > > To make a test build I just commented it out but I think that this patch should remove that if statement as well. thanks, indeed this was wrong, i tested the wrong branch on x86_64. i will fix this and post a v2 set with the other feedback. > > diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h > index 9a876a371e..2b1b36a739 100644 > --- a/sysdeps/x86_64/dl-machine.h > +++ b/sysdeps/x86_64/dl-machine.h > @@ -127,9 +127,11 @@ elf_machine_runtime_setup (struct link_map *l, int lazy, int profile) > } > } > > - if (l->l_info[ADDRIDX (DT_TLSDESC_GOT)] && lazy) > - *(ElfW(Addr)*)(D_PTR (l, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + l->l_addr) > - = (ElfW(Addr)) &_dl_tlsdesc_resolve_rela; > + /* Lazy binding of TLSDESC relocations is no longer done so this logic > + won't apply */ > + /* if (l->l_info[ADDRIDX (DT_TLSDESC_GOT)] && lazy) */ > + /* *(ElfW(Addr)*)(D_PTR (l, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + l->l_addr) */ > + /* = (ElfW(Addr)) &_dl_tlsdesc_resolve_rela; */ > > return lazy; > } > > > > On Feb 15, 2021, at 4:02 AM, Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> wrote: > > > > Lazy tlsdesc relocation is racy because the static tls optimization and > > tlsdesc management operations are done without holding the dlopen lock. > > > > This similar to the commit b7cf203b5c17dd6d9878537d41e0c7cc3d270a67 > > for aarch64, but it fixes a different race: bug 27137. > > --- > > sysdeps/x86_64/dl-machine.h | 19 ++++++++++++++----- > > 1 file changed, 14 insertions(+), 5 deletions(-) > > > > diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h > > index 103eee6c3f..9a876a371e 100644 > > --- a/sysdeps/x86_64/dl-machine.h > > +++ b/sysdeps/x86_64/dl-machine.h > > @@ -570,12 +570,21 @@ elf_machine_lazy_rel (struct link_map *map, > > } > > else if (__glibc_likely (r_type == R_X86_64_TLSDESC)) > > { > > - struct tlsdesc volatile * __attribute__((__unused__)) td = > > - (struct tlsdesc volatile *)reloc_addr; > > + const Elf_Symndx symndx = ELFW (R_SYM) (reloc->r_info); > > + const ElfW (Sym) *symtab = (const void *)D_PTR (map, l_info[DT_SYMTAB]); > > + const ElfW (Sym) *sym = &symtab[symndx]; > > + const struct r_found_version *version = NULL; > > > > - td->arg = (void*)reloc; > > - td->entry = (void*)(D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_PLT)]) > > - + map->l_addr); > > + if (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) > > + { > > + const ElfW (Half) *vernum = > > + (const void *)D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); > > + version = &map->l_versions[vernum[symndx] & 0x7fff]; > > + } > > + > > + /* Always initialize TLS descriptors completely at load time, in > > + case static TLS is allocated for it that requires locking. */ > > + elf_machine_rela (map, reloc, sym, version, reloc_addr, skip_ifunc); > > } > > else if (__glibc_unlikely (r_type == R_X86_64_IRELATIVE)) > > { > > -- > > 2.17.1 > > > --
> On Apr 9, 2021, at 6:38 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > > The 04/08/2021 17:14, Ben Woodard wrote: >> Don’t you also need to modify elf_machine_runtime_setup It also has a reference to _dl_tlsdesc_resolve_rela that becomes undefined when you try to compile with your patchset including patch 13 where you remove the code. >> >> To make a test build I just commented it out but I think that this patch should remove that if statement as well. > > thanks, > indeed this was wrong, i tested the wrong branch on x86_64. > > i will fix this and post a v2 set with the other feedback. On the positive side, I’ve been tracking down a problem where a library compiled with the gnu2 variant of TLS in a way that I haven’t been able to reproduce yet is crashing the dynamic loader when used with a performance tool that uses LD_AUDIT. This patch alone (with my tiny modification below) addresses the problem. I say “addresses” because it doesn’t exactly fix the problem; it makes it so that the code with the bug in it isn’t run. Patch 13 in your patch set removes the code with the bug in it. I see that patches 1 and 2 of your patch set have already been committed. I would encourage you to consider committing V2 of patch 11 and 13 (or maybe 11-14) even before the rest of the patch set since it addresses a bug that we are seeing in the wild. -ben > >> >> diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h >> index 9a876a371e..2b1b36a739 100644 >> --- a/sysdeps/x86_64/dl-machine.h >> +++ b/sysdeps/x86_64/dl-machine.h >> @@ -127,9 +127,11 @@ elf_machine_runtime_setup (struct link_map *l, int lazy, int profile) >> } >> } >> >> - if (l->l_info[ADDRIDX (DT_TLSDESC_GOT)] && lazy) >> - *(ElfW(Addr)*)(D_PTR (l, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + l->l_addr) >> - = (ElfW(Addr)) &_dl_tlsdesc_resolve_rela; >> + /* Lazy binding of TLSDESC relocations is no longer done so this logic >> + won't apply */ >> + /* if (l->l_info[ADDRIDX (DT_TLSDESC_GOT)] && lazy) */ >> + /* *(ElfW(Addr)*)(D_PTR (l, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + l->l_addr) */ >> + /* = (ElfW(Addr)) &_dl_tlsdesc_resolve_rela; */ >> >> return lazy; >> } >> >> >>> On Feb 15, 2021, at 4:02 AM, Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> wrote: >>> >>> Lazy tlsdesc relocation is racy because the static tls optimization and >>> tlsdesc management operations are done without holding the dlopen lock. >>> >>> This similar to the commit b7cf203b5c17dd6d9878537d41e0c7cc3d270a67 >>> for aarch64, but it fixes a different race: bug 27137. >>> --- >>> sysdeps/x86_64/dl-machine.h | 19 ++++++++++++++----- >>> 1 file changed, 14 insertions(+), 5 deletions(-) >>> >>> diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h >>> index 103eee6c3f..9a876a371e 100644 >>> --- a/sysdeps/x86_64/dl-machine.h >>> +++ b/sysdeps/x86_64/dl-machine.h >>> @@ -570,12 +570,21 @@ elf_machine_lazy_rel (struct link_map *map, >>> } >>> else if (__glibc_likely (r_type == R_X86_64_TLSDESC)) >>> { >>> - struct tlsdesc volatile * __attribute__((__unused__)) td = >>> - (struct tlsdesc volatile *)reloc_addr; >>> + const Elf_Symndx symndx = ELFW (R_SYM) (reloc->r_info); >>> + const ElfW (Sym) *symtab = (const void *)D_PTR (map, l_info[DT_SYMTAB]); >>> + const ElfW (Sym) *sym = &symtab[symndx]; >>> + const struct r_found_version *version = NULL; >>> >>> - td->arg = (void*)reloc; >>> - td->entry = (void*)(D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_PLT)]) >>> - + map->l_addr); >>> + if (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) >>> + { >>> + const ElfW (Half) *vernum = >>> + (const void *)D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); >>> + version = &map->l_versions[vernum[symndx] & 0x7fff]; >>> + } >>> + >>> + /* Always initialize TLS descriptors completely at load time, in >>> + case static TLS is allocated for it that requires locking. */ >>> + elf_machine_rela (map, reloc, sym, version, reloc_addr, skip_ifunc); >>> } >>> else if (__glibc_unlikely (r_type == R_X86_64_IRELATIVE)) >>> { >>> -- >>> 2.17.1 >>> >> > > --
diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h index 103eee6c3f..9a876a371e 100644 --- a/sysdeps/x86_64/dl-machine.h +++ b/sysdeps/x86_64/dl-machine.h @@ -570,12 +570,21 @@ elf_machine_lazy_rel (struct link_map *map, } else if (__glibc_likely (r_type == R_X86_64_TLSDESC)) { - struct tlsdesc volatile * __attribute__((__unused__)) td = - (struct tlsdesc volatile *)reloc_addr; + const Elf_Symndx symndx = ELFW (R_SYM) (reloc->r_info); + const ElfW (Sym) *symtab = (const void *)D_PTR (map, l_info[DT_SYMTAB]); + const ElfW (Sym) *sym = &symtab[symndx]; + const struct r_found_version *version = NULL; - td->arg = (void*)reloc; - td->entry = (void*)(D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_PLT)]) - + map->l_addr); + if (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) + { + const ElfW (Half) *vernum = + (const void *)D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); + version = &map->l_versions[vernum[symndx] & 0x7fff]; + } + + /* Always initialize TLS descriptors completely at load time, in + case static TLS is allocated for it that requires locking. */ + elf_machine_rela (map, reloc, sym, version, reloc_addr, skip_ifunc); } else if (__glibc_unlikely (r_type == R_X86_64_IRELATIVE)) {