Message ID | 299d28c6695cd2e76f222b0d36b17b7124c549e7.1618301209.git.szabolcs.nagy@arm.com |
---|---|
State | Committed |
Commit | 572bd547d57a39b6cf0ea072545dc4048921f4c3 |
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 205A43982077; Tue, 13 Apr 2021 08:20:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 205A43982077 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1618302034; bh=xI4HhTiZQSuBUv2nCDJliLR3jzjqJlrPMoxOoThSUCE=; 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=ctglwbYmhT8kbByKQWc17Nf3VpDL6suIAn1rdxY+gXYhMPE2HkjsfNuMH00oSjArQ DQPO48c/hEtWa4YTpV5ZyAKgkPcYDelawxDER/b/uFBT4HrqzkU/bmCAcCpV+iUVr0 QIzIohS7H8Nbnuxzac9qh8w9oieJauQuvWcMT8p8= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2044.outbound.protection.outlook.com [40.107.20.44]) by sourceware.org (Postfix) with ESMTPS id 45D22393D013 for <libc-alpha@sourceware.org>; Tue, 13 Apr 2021 08:20:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 45D22393D013 Received: from DB6PR1001CA0024.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::34) by AM4PR08MB2897.eurprd08.prod.outlook.com (2603:10a6:205:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Tue, 13 Apr 2021 08:20:25 +0000 Received: from DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b7:cafe::7a) by DB6PR1001CA0024.outlook.office365.com (2603:10a6:4:b7::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17 via Frontend Transport; Tue, 13 Apr 2021 08:20: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 DB5EUR03FT044.mail.protection.outlook.com (10.152.21.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17 via Frontend Transport; Tue, 13 Apr 2021 08:20:25 +0000 Received: ("Tessian outbound 82c2d58b350b:v90"); Tue, 13 Apr 2021 08:20:25 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 23ae5e034a2130af X-CR-MTA-TID: 64aa7808 Received: from cc48a6b18337.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 14FC7FCE-B1C7-48DF-A54E-13EEFB350900.1; Tue, 13 Apr 2021 08:20:18 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cc48a6b18337.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 13 Apr 2021 08:20:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=StkWBkf3SOH66+zLXzadyMcfwLALbUTZZqkrTY4IOBW0s1noyf3RBpEWmvYVz6A/tOgjRnxM7hu5D9zrPsWwmkoCyXnWFTFXvRrjrqpMxzDV2MYYbhyHBb32tGbq8rrg90uFfx5ZXV0djfJoydUrE1u0F/jo8iL3jaloiagddBOsVzW7vziQk7XAyJdcdGditTZ81aRn7BVUum0LRa1wL6/ZfBgtBvdvw4knWEKv9a6dfiNwtjbnZGy0oVFhbShOJjuKL6bly8ZZ9EXsTuzA3PdGKDQzEG2j9w0kkKGgEGCOvz+TsMxPp6F7Yhy/Yll/v8KzKTTAw4gLaVzehXYpTQ== 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=xI4HhTiZQSuBUv2nCDJliLR3jzjqJlrPMoxOoThSUCE=; b=ApvvDNTQqabI3y68/pPggvpL666SrgcLCHm+FqZNd/xoKzTSjwqojfv1LMJYopBaaI2iv5XtEvB+S+E+LyrxXTr8cFA6NwsRXNBkX35osEif91eGXE+9E+i1vIvGfTUoJkTEZpKxB7RXMT2IXj117s6hBnjmn5XQj9Jlls0c12GDqL3wwYixb30j34aVvGbxqf+grUu+6lf2ZrsRyKITCNcthhr0uytf3YrHM/MbcgOiltkxW/lyiCL10heYdLETIpNyTQZC2P8iaI69UvJqhtAojle7039k9K6xxHiv/Ogkiy57mxuaUx3u3BkHorQKkhY8Lsezd/Ll6fKTrAWebA== 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 PAXPR08MB6558.eurprd08.prod.outlook.com (2603:10a6:102:151::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Tue, 13 Apr 2021 08:20:17 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::c99f:671d:bb2c:f20b]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::c99f:671d:bb2c:f20b%7]) with mapi id 15.20.4020.022; Tue, 13 Apr 2021 08:20:17 +0000 To: libc-alpha@sourceware.org Subject: [PATCH v2 08/14] elf: Fix DTV gap reuse logic [BZ #27135] Date: Tue, 13 Apr 2021 09:20:11 +0100 Message-Id: <299d28c6695cd2e76f222b0d36b17b7124c549e7.1618301209.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1618301209.git.szabolcs.nagy@arm.com> References: <cover.1618301209.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-Originating-IP: [217.140.106.55] X-ClientProxiedBy: LO3P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::13) 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.55) by LO3P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22 via Frontend Transport; Tue, 13 Apr 2021 08:20:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cebfd47c-76fe-451a-3e70-08d8fe54fd66 X-MS-TrafficTypeDiagnostic: PAXPR08MB6558:|AM4PR08MB2897: X-Microsoft-Antispam-PRVS: <AM4PR08MB28972205AEDAA35A67C4C355ED4F9@AM4PR08MB2897.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 4o1YxE5SoE4UQtMNDeQ1dmdEGL63Wgkik3yUxRH+SvjxUqZPqqHXMOkcSIhY5CtPt4RGOz9r1HRF2DH/ybVi4joLZ1a523jIoDc8Qj4WG9zfaVqLsSlCF94OVfUPju2ZUG0EZP/XYh+XrY/e9xQUJxjNvbDjpDOBChLq90GYa8W6dlUr/9APLa2pe4W7U5Dq/g1YwYjs3+Idlq274AvHhmCyzS91KTcezsEl6IPdbGQ2qcUDKQmN7ouxyDV2NtfkhtXE5ZKZdNdqTAOt+dhusCbn3uagyzn7hjoA7CRxE8ZB2J+/FHbPDkppx+tGgHia8TPo6TH2HomWJbjS7TdpR2SkN8PnrICUmK4TQw0Jot5f/i4dmzBpMMw+Gadpu1NzBhzGR0f7QzqOsd2P3bsik6AXs4RG2vSEPs5dyT53YXn4isQ8QZxffFt35lHrNsrmOvRdwietqS+IOd8QBhgQ6Do/D8uVKi/XfciafozuNvLaxJD9JtlDFP1MZZQHrX0dR3GxlIWTQ68VUgvAxUSKufyivZpASFNIIkvqd58+g4Jh2Pw6p67kBk+8zwUfy3bmPAQfp1wvPUMD2TzGdgJTetMu/mSQuna5pNHIyJUt83VDVvJQnYzgvi5ddTj/kn+KuafJzP+W2PJWtCE+qS2yVuoPgMHvkeymfNxHy+VH7KTlwzj4omw4CemrAWCm8ljr 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)(366004)(376002)(136003)(39860400002)(346002)(396003)(26005)(69590400012)(66556008)(44832011)(316002)(66476007)(6512007)(16526019)(38100700002)(8676002)(66946007)(38350700002)(52116002)(186003)(478600001)(2616005)(86362001)(2906002)(6666004)(5660300002)(6486002)(956004)(6506007)(6916009)(83380400001)(36756003)(8936002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: aybMPtzdEkjMOg+DcMiEGvD10bauslOWxp+sLMwD+L70UGH4EAGNPzcyKqV9+ahiSMCggqbT8RHmBjn5g3UVYW9hAtfz+crlDu5dFgogbgVGJ7y5pOicZrlQJeUYQD3vG61AC99hL07PyCPXM9touExlpj/6d33ToSUTK4h/CRgWDUye5iR9fF/IWN6OLFUvwnnHHNvDuh4/22WNNlJlH1C536nlP5y56fC/ay3ixoFEHyly4qT02C0PApBhjH8AcOlMhNkE8qWJ5YjUhGi81FOOsj1UVAjbOde+NZOQJ+VBHqy5PlQO8nsSy8dKZp1VcC+WZ3ZBxBZkmvx57ETlClU3d6hokts810yHGK6QCyJd41h8ALque8xwTbWPcIWYNl6HUbJbEDCySvQUUd17nxlUsIIjudd2XFCnaUCChtAFnEFu76fVqvIprBEfYe5rPjxoakOvtYrgEovuXo0Rv+/NRF92YReekoVOn100I7Y1r8iOHlTVyVLzfeOFR517hBvTM1q783caYvL2HgVYSjRuMXDUYXClLe3NCXi67UmP/7V5HhjxgtlkOJa+oFmleT6JJQ79qRoSnz3YwueMyRgUD9cMBUWBGWmemfhoIlQ2wWVwm4Y0AZRHa6O0T4m1iPnuauFYNGu7exT5JPa3D6yGYfFjW+x5Y/wsAY+uW7lsGoB4SDXUm+FHDWzDkEcYERFLVtlljuGUN0hmsFsUuA9cIVjVGC2SCPFDPaCpgF88KS4/gVsOKtvfR2jJFEtyyMhrlUzgyogFL/LiOeRINUvMh553f+fq6akBtbu8bl3iImuM7/ma4NKUJ/MR1yjZzBmQEQKxGImByDdiZPj9s7CL2uf4+j0siYHc1u3FnvfZgCfbWHwi3FVudGQldktb0XCR2bIfSmAmsARCXboHXrhcPtI+u2nDWkdtecMjXAg74j739mhkKx5nZuO8X7iF69ZDsS0Z8V0vnRa7ccc3ayiMBnTfYPBOjmnAOZge/P9O3nrm/xVqAkwe0vsxxunLRJlgBTuDqDRCUot6V1LXYwe10YLFNlyiui0H9MgimtTk97tKKLtqtV0TkjQ5LTHDqkMOmFUN2zFTFV5g68TydXd1ONsQypcz0jtIhpgwNEHp/MBuJvDIPFhBfky+28jiJGEhq7rQJz5gP2K3eRWJcnQbEOyT5GYWq2LPIXLTctPc5MFjoW4CEM+AtjduHUYN6iDrQbXM0nTL4RK0kdFKRibuAhAnEGpvrjANaOTv39dJ9e7235yI7bg593Otzbxy8jggOYxJ99D4C+HmfTPRecUkLvoOuIs7jR7XMPWCIcmxYNY9TAdJnDTUAkLbweCk X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB6558 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: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 2dcf3b79-8114-4beb-0e05-08d8fe54f84a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sD7/7f1a+TiN3mOHkEoIo4h5IDjMGIwrki+avKm06OhKE0Tf7CJEaZizrUtQCSbaoICx7MKv0HmXrkPMk3zbSlkSr8vnF6ZlplIHJe+Nr9/uej9d6VVOQdU8xOGDO0ybEBA6gLflfBXLySTQd8Rvwk5NBc/XhCWNA+d535xn3CX/3+He0jIxNn+LPPRTJx8QsL8JLBAR1wbp6XDJfwi3Dh6HIgklYind1gEclEn5XMGdiZneJp1cRHRD9LKDoexwx+I/DdZfXtRqWL4/Z0E7LCoaFNXNhFsULx3t/6nvfVAiobvihK/7J5OLAN7/d1AT0H1RWafpc/mUdF46XImNBFv1xMDZ/zqBg1zwfhp7Y2vQHbu6yQRLrE2r6AQi2f+m1hNJdRrMvSm3aXsSAz2g9lVeOa4sNI/xgWSRlumi+ACuwe3ZK0I71vA6bQa75+C5dp16c4yFCK6bdxV4i5Yv8iRZc1wyXbzw9Z/EynSA61aehK+/KtptRmsm5YDWLv8J9IO4NiLh/GVZjn5ted04vmXfnt5shHd3UCAceIhmdaN6MrCH209MdMDCdKXlHmAnJtmRwzeK+pJOShzjWcDrGqzm9acJP462ecMrnTTc1gsbP4y0wmh6lB8Bkdo3sktks9drTKCAXNAx8yVyUvGBXkJ4RipuqELyPx17NUFp8/x5gOKcYBhR/HbCPcc15Tnd 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)(136003)(376002)(346002)(39860400002)(396003)(46966006)(36840700001)(82740400003)(6512007)(86362001)(69590400012)(6506007)(70206006)(478600001)(316002)(2906002)(83380400001)(6486002)(956004)(26005)(36860700001)(5660300002)(2616005)(36756003)(47076005)(186003)(336012)(70586007)(356005)(81166007)(82310400003)(44832011)(16526019)(8676002)(8936002)(6666004)(6916009); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2021 08:20:25.4899 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cebfd47c-76fe-451a-3e70-08d8fe54fd66 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: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB2897 X-Spam-Status: No, score=-13.8 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
April 13, 2021, 8:20 a.m. UTC
For some reason only dlopen failure caused dtv gaps to be reused. It is possible that the intent was to never reuse modids for a different module, but after dlopen failure all gaps are reused not just the ones caused by the unfinished dlopened. So the code has to handle reused modids already which seems to work, however the data races at thread creation and tls access (see bug 19329 and bug 27111) may be more severe if slots are reused so this is scheduled after those fixes. I think fixing the races are not simpler if reuse is disallowed and reuse has other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are removed from the middle of the slotinfo list. The value does not have to be correct: incorrect true value causes the next modid query to do a slotinfo walk, incorrect false will leave gaps and new entries are added at the end. Fixes bug 27135. --- elf/dl-close.c | 6 +++++- elf/dl-open.c | 10 ---------- elf/dl-tls.c | 5 +---- 3 files changed, 6 insertions(+), 15 deletions(-)
Comments
On 13/04/2021 05:20, Szabolcs Nagy via Libc-alpha wrote: > For some reason only dlopen failure caused dtv gaps to be reused. > > It is possible that the intent was to never reuse modids for a > different module, but after dlopen failure all gaps are reused > not just the ones caused by the unfinished dlopened. > > So the code has to handle reused modids already which seems to > work, however the data races at thread creation and tls access > (see bug 19329 and bug 27111) may be more severe if slots are > reused so this is scheduled after those fixes. I think fixing > the races are not simpler if reuse is disallowed and reuse has > other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are > removed from the middle of the slotinfo list. The value does > not have to be correct: incorrect true value causes the next > modid query to do a slotinfo walk, incorrect false will leave > gaps and new entries are added at the end. > > Fixes bug 27135. LGTM, thanks. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > --- > elf/dl-close.c | 6 +++++- > elf/dl-open.c | 10 ---------- > elf/dl-tls.c | 5 +---- > 3 files changed, 6 insertions(+), 15 deletions(-) > > diff --git a/elf/dl-close.c b/elf/dl-close.c > index 3720e47dd1..9f31532f41 100644 > --- a/elf/dl-close.c > +++ b/elf/dl-close.c > @@ -88,7 +88,11 @@ remove_slotinfo (size_t idx, struct dtv_slotinfo_list *listp, size_t disp, > /* If this is not the last currently used entry no need to look > further. */ > if (idx != GL(dl_tls_max_dtv_idx)) > - return true; > + { > + /* There is an unused dtv entry in the middle. */ > + GL(dl_tls_dtv_gaps) = true; > + return true; > + } > } > > while (idx - disp > (disp == 0 ? 1 + GL(dl_tls_static_nelem) : 0)) Ok. > diff --git a/elf/dl-open.c b/elf/dl-open.c > index 83b8e96a5c..661f26977e 100644 > --- a/elf/dl-open.c > +++ b/elf/dl-open.c > @@ -890,16 +890,6 @@ no more namespaces available for dlmopen()")); > state if relocation failed, for example. */ > if (args.map) > { > - /* Maybe some of the modules which were loaded use TLS. > - Since it will be removed in the following _dl_close call > - we have to mark the dtv array as having gaps to fill the > - holes. This is a pessimistic assumption which won't hurt > - if not true. There is no need to do this when we are > - loading the auditing DSOs since TLS has not yet been set > - up. */ > - if ((mode & __RTLD_AUDIT) == 0) > - GL(dl_tls_dtv_gaps) = true; > - > _dl_close_worker (args.map, true); > > /* All l_nodelete_pending objects should have been deleted Ok. > diff --git a/elf/dl-tls.c b/elf/dl-tls.c > index c4466bd9fc..b0257185e9 100644 > --- a/elf/dl-tls.c > +++ b/elf/dl-tls.c > @@ -187,10 +187,7 @@ _dl_next_tls_modid (void) > size_t > _dl_count_modids (void) > { > - /* It is rare that we have gaps; see elf/dl-open.c (_dl_open) where > - we fail to load a module and unload it leaving a gap. If we don't > - have gaps then the number of modids is the current maximum so > - return that. */ > + /* The count is the max unless dlclose or failed dlopen created gaps. */ > if (__glibc_likely (!GL(dl_tls_dtv_gaps))) > return GL(dl_tls_max_dtv_idx); > > Ok.
* Szabolcs Nagy via Libc-alpha: > For some reason only dlopen failure caused dtv gaps to be reused. > > It is possible that the intent was to never reuse modids for a > different module, but after dlopen failure all gaps are reused > not just the ones caused by the unfinished dlopened. > > So the code has to handle reused modids already which seems to > work, however the data races at thread creation and tls access > (see bug 19329 and bug 27111) may be more severe if slots are > reused so this is scheduled after those fixes. I think fixing > the races are not simpler if reuse is disallowed and reuse has > other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are > removed from the middle of the slotinfo list. The value does > not have to be correct: incorrect true value causes the next > modid query to do a slotinfo walk, incorrect false will leave > gaps and new entries are added at the end. > > Fixes bug 27135. > --- > elf/dl-close.c | 6 +++++- > elf/dl-open.c | 10 ---------- > elf/dl-tls.c | 5 +---- > 3 files changed, 6 insertions(+), 15 deletions(-) Apparently this broke GNOME Shell: <https://bugzilla.redhat.com/show_bug.cgi?id=1974970> I'm trying to figure out why. Thanks, Florian
* Florian Weimer: > * Szabolcs Nagy via Libc-alpha: > >> For some reason only dlopen failure caused dtv gaps to be reused. >> >> It is possible that the intent was to never reuse modids for a >> different module, but after dlopen failure all gaps are reused >> not just the ones caused by the unfinished dlopened. >> >> So the code has to handle reused modids already which seems to >> work, however the data races at thread creation and tls access >> (see bug 19329 and bug 27111) may be more severe if slots are >> reused so this is scheduled after those fixes. I think fixing >> the races are not simpler if reuse is disallowed and reuse has >> other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are >> removed from the middle of the slotinfo list. The value does >> not have to be correct: incorrect true value causes the next >> modid query to do a slotinfo walk, incorrect false will leave >> gaps and new entries are added at the end. >> >> Fixes bug 27135. >> --- >> elf/dl-close.c | 6 +++++- >> elf/dl-open.c | 10 ---------- >> elf/dl-tls.c | 5 +---- >> 3 files changed, 6 insertions(+), 15 deletions(-) > > Apparently this broke GNOME Shell: > > <https://bugzilla.redhat.com/show_bug.cgi?id=1974970> > > I'm trying to figure out why. The bug is that if there is a gap, _dl_next_tls_modid does not update the slotinfo list to mark the modid to be returned as reserved, so multiple calls in a single dlopen operation keep returning the same modid. I'm not yet sure what the proper fix is for that. Thanks, Florian
On 24/06/2021 09:27, Florian Weimer via Libc-alpha wrote: > * Florian Weimer: > >> * Szabolcs Nagy via Libc-alpha: >> >>> For some reason only dlopen failure caused dtv gaps to be reused. >>> >>> It is possible that the intent was to never reuse modids for a >>> different module, but after dlopen failure all gaps are reused >>> not just the ones caused by the unfinished dlopened. >>> >>> So the code has to handle reused modids already which seems to >>> work, however the data races at thread creation and tls access >>> (see bug 19329 and bug 27111) may be more severe if slots are >>> reused so this is scheduled after those fixes. I think fixing >>> the races are not simpler if reuse is disallowed and reuse has >>> other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are >>> removed from the middle of the slotinfo list. The value does >>> not have to be correct: incorrect true value causes the next >>> modid query to do a slotinfo walk, incorrect false will leave >>> gaps and new entries are added at the end. >>> >>> Fixes bug 27135. >>> --- >>> elf/dl-close.c | 6 +++++- >>> elf/dl-open.c | 10 ---------- >>> elf/dl-tls.c | 5 +---- >>> 3 files changed, 6 insertions(+), 15 deletions(-) >> >> Apparently this broke GNOME Shell: >> >> <https://bugzilla.redhat.com/show_bug.cgi?id=1974970> >> >> I'm trying to figure out why. > > The bug is that if there is a gap, _dl_next_tls_modid does not update > the slotinfo list to mark the modid to be returned as reserved, so > multiple calls in a single dlopen operation keep returning the same > modid. > > I'm not yet sure what the proper fix is for that. How hard would be to create a testcase for this?
* Adhemerval Zanella via Libc-alpha: > On 24/06/2021 09:27, Florian Weimer via Libc-alpha wrote: >> * Florian Weimer: >> >>> * Szabolcs Nagy via Libc-alpha: >>> >>>> For some reason only dlopen failure caused dtv gaps to be reused. >>>> >>>> It is possible that the intent was to never reuse modids for a >>>> different module, but after dlopen failure all gaps are reused >>>> not just the ones caused by the unfinished dlopened. >>>> >>>> So the code has to handle reused modids already which seems to >>>> work, however the data races at thread creation and tls access >>>> (see bug 19329 and bug 27111) may be more severe if slots are >>>> reused so this is scheduled after those fixes. I think fixing >>>> the races are not simpler if reuse is disallowed and reuse has >>>> other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are >>>> removed from the middle of the slotinfo list. The value does >>>> not have to be correct: incorrect true value causes the next >>>> modid query to do a slotinfo walk, incorrect false will leave >>>> gaps and new entries are added at the end. >>>> >>>> Fixes bug 27135. >>>> --- >>>> elf/dl-close.c | 6 +++++- >>>> elf/dl-open.c | 10 ---------- >>>> elf/dl-tls.c | 5 +---- >>>> 3 files changed, 6 insertions(+), 15 deletions(-) >>> >>> Apparently this broke GNOME Shell: >>> >>> <https://bugzilla.redhat.com/show_bug.cgi?id=1974970> >>> >>> I'm trying to figure out why. >> >> The bug is that if there is a gap, _dl_next_tls_modid does not update >> the slotinfo list to mark the modid to be returned as reserved, so >> multiple calls in a single dlopen operation keep returning the same >> modid. >> >> I'm not yet sure what the proper fix is for that. > > How hard would be to create a testcase for this? Not particularly hard, I think. We need six modules (mod1 to mod6), all using dynamic TLS with different symbols (sym1 to sym6). mod4 depends on mod5 and mod6, but no other dependencies. dlopen mod1 dlopen mod2 dlopen mod3 dlclose mod2 # create modid gap dlclose mod1 # more modid gap dlopen mod4 Then check that all six TLS variables have different addresses. If the bug is present, sym4 to to sym6 should all have the same address because the modid is the same. I have not written a test yet and won't get to it today. Thanks, Florian
The 06/24/2021 14:27, Florian Weimer wrote: > * Florian Weimer: > > > * Szabolcs Nagy via Libc-alpha: > > > >> For some reason only dlopen failure caused dtv gaps to be reused. > >> > >> It is possible that the intent was to never reuse modids for a > >> different module, but after dlopen failure all gaps are reused > >> not just the ones caused by the unfinished dlopened. > >> > >> So the code has to handle reused modids already which seems to > >> work, however the data races at thread creation and tls access > >> (see bug 19329 and bug 27111) may be more severe if slots are > >> reused so this is scheduled after those fixes. I think fixing > >> the races are not simpler if reuse is disallowed and reuse has > >> other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are > >> removed from the middle of the slotinfo list. The value does > >> not have to be correct: incorrect true value causes the next > >> modid query to do a slotinfo walk, incorrect false will leave > >> gaps and new entries are added at the end. > >> > >> Fixes bug 27135. > >> --- > >> elf/dl-close.c | 6 +++++- > >> elf/dl-open.c | 10 ---------- > >> elf/dl-tls.c | 5 +---- > >> 3 files changed, 6 insertions(+), 15 deletions(-) > > > > Apparently this broke GNOME Shell: > > > > <https://bugzilla.redhat.com/show_bug.cgi?id=1974970> > > > > I'm trying to figure out why. > > The bug is that if there is a gap, _dl_next_tls_modid does not update > the slotinfo list to mark the modid to be returned as reserved, so > multiple calls in a single dlopen operation keep returning the same > modid. > > I'm not yet sure what the proper fix is for that. this patch is not critical for the other tls issues i fixed for 2.34, so it should be safe to revert. this might have been the reason why gap reuse was not enabled. but if _dl_next_tls_modid is broken then likely a failed dlopen can trigger that on old glibc too, so a fix would be nice. thanks for debugging this.
diff --git a/elf/dl-close.c b/elf/dl-close.c index 3720e47dd1..9f31532f41 100644 --- a/elf/dl-close.c +++ b/elf/dl-close.c @@ -88,7 +88,11 @@ remove_slotinfo (size_t idx, struct dtv_slotinfo_list *listp, size_t disp, /* If this is not the last currently used entry no need to look further. */ if (idx != GL(dl_tls_max_dtv_idx)) - return true; + { + /* There is an unused dtv entry in the middle. */ + GL(dl_tls_dtv_gaps) = true; + return true; + } } while (idx - disp > (disp == 0 ? 1 + GL(dl_tls_static_nelem) : 0)) diff --git a/elf/dl-open.c b/elf/dl-open.c index 83b8e96a5c..661f26977e 100644 --- a/elf/dl-open.c +++ b/elf/dl-open.c @@ -890,16 +890,6 @@ no more namespaces available for dlmopen()")); state if relocation failed, for example. */ if (args.map) { - /* Maybe some of the modules which were loaded use TLS. - Since it will be removed in the following _dl_close call - we have to mark the dtv array as having gaps to fill the - holes. This is a pessimistic assumption which won't hurt - if not true. There is no need to do this when we are - loading the auditing DSOs since TLS has not yet been set - up. */ - if ((mode & __RTLD_AUDIT) == 0) - GL(dl_tls_dtv_gaps) = true; - _dl_close_worker (args.map, true); /* All l_nodelete_pending objects should have been deleted diff --git a/elf/dl-tls.c b/elf/dl-tls.c index c4466bd9fc..b0257185e9 100644 --- a/elf/dl-tls.c +++ b/elf/dl-tls.c @@ -187,10 +187,7 @@ _dl_next_tls_modid (void) size_t _dl_count_modids (void) { - /* It is rare that we have gaps; see elf/dl-open.c (_dl_open) where - we fail to load a module and unload it leaving a gap. If we don't - have gaps then the number of modids is the current maximum so - return that. */ + /* The count is the max unless dlclose or failed dlopen created gaps. */ if (__glibc_likely (!GL(dl_tls_dtv_gaps))) return GL(dl_tls_max_dtv_idx);