From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40088.outbound.protection.outlook.com [40.107.4.88]) by sourceware.org (Postfix) with ESMTPS id 6EF5B385803B for ; Tue, 11 May 2021 09:31:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6EF5B385803B Received: from MR2P264CA0036.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500::24) by VI1PR08MB3536.eurprd08.prod.outlook.com (2603:10a6:803:79::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25; Tue, 11 May 2021 09:31:18 +0000 Received: from VE1EUR03FT059.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:0:cafe::1f) by MR2P264CA0036.outlook.office365.com (2603:10a6:500::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Tue, 11 May 2021 09:31:18 +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 VE1EUR03FT059.mail.protection.outlook.com (10.152.19.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Tue, 11 May 2021 09:31:18 +0000 Received: ("Tessian outbound 52fcc5bd9d3a:v91"); Tue, 11 May 2021 09:31:17 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2d15b3d4500c17e7 X-CR-MTA-TID: 64aa7808 Received: from 2d8523aefa1d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F2963C81-6D7C-4CAF-896F-CAFF7CCAD9B7.1; Tue, 11 May 2021 09:31:10 +0000 Received: from FRA01-MR2-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2d8523aefa1d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 11 May 2021 09:31:10 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cg7IF9lHCV1S58egh0ahfDm8GwUWS/17A/gEggAj2J7Dzn1BUxK3rOZCaKfaqqRvQLfXqe7WqvsORTJdlCQAVqxMKdtU8oKmijrghsf75tYmcrNpoMShIvRixDOekr1Gw5/WUuIQI2GZh64hE8yc06sRdo6zg0Djin5WNyD/QgpoH4NP04kBOkicSJ+VVLCxm1AZ7PwaaqA9EDgc1yXVTU4+PYqXz/94kCveVr1QlzNokustr1VhZCC4HgrKZ4bF1C0f9UYu4futB/wCjPXD5RFFvubzf1sagVNMtgeKhdj6RSwzCU5OJ0OOOSzx1kZDUZR4CDWJ6UBocyLQ+RmZww== 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=GQ05QV5r+C6OdAjYktIIpK/eTahjkDjuRw5+Y0AdJ3Q=; b=RQOfuK3iLx8w03J9WK6j238MVN+TZVXPmxDDUiftPYS5OFTZLHTxL/hU43hTRSd8/wvL7NpOjpAvfVj+GSP/ICodbHjNTakmFB5yXGiuP+4fHAZK4ChGsXSv4qY9umvDFxgmdr5zhI/mBdnhhGIH7OBoMKPbNojgdcN1VIL4GK7EEE/ZuiRd5DrtWQr/wF58+IvHio1GedWPxW5TGM5KwWyb82RAufUyBrso/plhtZtSAK/d05LzqbBTUBSUO0PxGcJUOVt9DUn+xE4xmhjp3CPypNgBCsgtvXyuT6wQ8C25TKBa4EgdcJpL78Lod9328N7UB0ckpUj2O7CU346Vhw== 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: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PR2PR08MB5226.eurprd08.prod.outlook.com (2603:10a6:101:24::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.29; Tue, 11 May 2021 09:31:08 +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.4129.025; Tue, 11 May 2021 09:31:08 +0000 Date: Tue, 11 May 2021 10:31:05 +0100 From: Szabolcs Nagy To: Carlos O'Donell Cc: Adhemerval Zanella , libc-alpha@sourceware.org Subject: Re: [PATCH v2 06/14] elf: Use relaxed atomics for racy accesses [BZ #19329] Message-ID: <20210511093105.GH9028@arm.com> References: <10fb15a36b3f6bc3e5ca62cda081c86512f47d32.1618301209.git.szabolcs.nagy@arm.com> <37965321-dec2-f901-325c-ac4bad72484f@linaro.org> <20210416091256.GA30290@arm.com> <0a69a61e-5500-8e01-658d-c5e4896c6489@redhat.com> Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <0a69a61e-5500-8e01-658d-c5e4896c6489@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [217.140.106.55] X-ClientProxiedBy: LO2P265CA0023.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::35) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.55) by LO2P265CA0023.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Tue, 11 May 2021 09:31:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 61282578-81c9-4da9-9af6-08d9145f87ce X-MS-TrafficTypeDiagnostic: PR2PR08MB5226:|VI1PR08MB3536: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:213;OLM:213; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: fbEnZCnZedOBO2P9K2UyzJ8HfBHsWIH9IGuVkcSVOaomvBcWAjuOf4Gv545WIttKxUZ44EROt1tAMHMxcqn2WN1hNTNWxE5Lpcr2b9lTuY8m4PaaN0UHhNdceVqjekllGvvOrnt2rMg3EspqhZ91MCDTqhh7CEgrUJrZIFDN8u99A6dgHSEjt/jdz7N6dznCyYenB/QffuHi7xv/yYfkMUh91ORldhJhZBZSUw7vSowkxhjN3eEcffYBggEdqqtRoc5e3hguVlCadVtrDO1XfJe0sq9oxYz0kIi3FDa6H18Ev2pQbTub/Q2zjoJu9iqgs5C2UwfKhLuryHlT2nR2fhjMtJyeW+oFBWBKoSsfLzSNSGuGdj3V0ZU1KQhPSutQjpWek7zbUygNdrgmBCiIwLmPQCKLaOUit4f8IiWRcE1RyBU7eCU3VuRfCwcX1b0KlW6ppumGuH/0k7d9Lgxo5zQsseDNjX7MxR20uszZ58tgS1SV2cZ2M0z9I4Q7v5ebNnJNceJdk4CU9FHujC+jRFF5c+L+DnyExJ/hT06q52NyFaQeotw0fSLRl+WbW6b5xdaL3yUVwZduACmJQdGSp6158TfwoRwqlGOkhesh11irW04H7BHLiEXoyaernZpCWoJWBXOEbfOGJFiDcOQyDpZOu9I89UXhIWFdk3kun30= 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)(376002)(346002)(136003)(366004)(39850400004)(396003)(83380400001)(5660300002)(36756003)(7696005)(1076003)(52116002)(44144004)(4326008)(66556008)(55016002)(66476007)(8676002)(66946007)(33656002)(33964004)(235185007)(478600001)(186003)(6916009)(2906002)(38350700002)(8936002)(53546011)(86362001)(316002)(8886007)(26005)(44832011)(38100700002)(16526019)(66616009)(956004)(2616005)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?cnhkcEo3WHpMdkFqbmNyR2d1MFQ2WXRyR0o5RkY4TlAxNlFubFJQenpOMmlU?= =?utf-8?B?bDlrdkUvVi9mQ2UzTGRkYmV2OExYWG9DUk9MU3ZsZ291UVhmR2E5RDA5MWxx?= =?utf-8?B?eGM1bG0vY0Q5TGU4aktpTDhVVFJZY3hFbEhHUFV3R0VPQklUdnAyZnQzaEJp?= =?utf-8?B?RVVhUEdOOC96eWxtKzRmMXZ2RlRzZXFyTjlrTElnRlJvWXpaclU4T3NiWVZx?= =?utf-8?B?aTNoZHNXeTJKMXYrUllUYnNFc08wdWNXaU52ZjlvWTIzdmR4R2k4Y1pFd3dU?= =?utf-8?B?ZGwxN1BmbnhTbFIrVDlKdi9mMlNXV0paQ0Z2YWlnMzRiU1c3OWRSanh2OEdl?= =?utf-8?B?L2FtcExJWS80a3dxM0ZIelNqWkpGWVNRQlI3KzBjY01KSSttSDlrSmFtclJk?= =?utf-8?B?UE9Ubm55VllUSWF6TXRtYkpJS1NhSHVMdC83ZVNHaGdqalpkdzYzaGVGYVlT?= =?utf-8?B?bmIvRlh0RmNUUU1yYStQeDBVRzc2NUJUTFpkWDlSNDN3WHBzeUp3cGFEZkRF?= =?utf-8?B?eFRINXU4RFppamRlNUVzcm9ZdUNsaFkrVWRMWVRXLzN5N2lpMEVNbHJFVFpM?= =?utf-8?B?SGZpWHdsZTdSckdlWFhVREQ0NVUvT3NwbWVnVXAwK1Bzay83NVRSdjI1SUR4?= =?utf-8?B?RFJqcS9sRnF3UVJ4ckhQb3M3L3JqdkhnOWtUZGpPcTZyL0Npb1QxTy91RlFY?= =?utf-8?B?aS80aFdFQmwvQTlCeU9zVllnZTg2WEc5b0JYUUtQL2RSc1hJdEVkY3FJVXgr?= =?utf-8?B?ZEt4ZmNJK2swdmg5a0RGL0N5VFM1Z3lzOW9wRjR2L0ZIUFNKelRLL3h2SWZi?= =?utf-8?B?clZINXlseUVLRnlkOGhBei9CS0hUdVRNaktKSEluamMxdytkN1NYUnVHVk5z?= =?utf-8?B?MzZ0UVVWNVgyU0cwNGw3bmtVQy9hVXNZaFhiQXpFSWZ1VTFySSttRnNvMHFQ?= =?utf-8?B?WUpUUmM4Si9FWFhub1FaZUVjYStlSUNqMHNKNXRaRWw0UEZxcTRwVndic29G?= =?utf-8?B?YzY0NEtWdG9wN1Rva2VzN09TN3JFTnpUZ3ZNMTZzOXQvSWx2K3V6M1dyY2pZ?= =?utf-8?B?VGIyNml6NEhjNUx6UjU1NnAwN0RIVWYwbWkwWDY1WW1YeUlhMVJ6amJuSFdV?= =?utf-8?B?WGcwU2w5WjJuUUhpbGREVmdXOFAva3oxUExqTnc2RW1BOFRsbVUxb2xIaEs4?= =?utf-8?B?SlZIOHlybm1Eejd0N05GcVM0aENVVEhWZ3hzSFNvWGZTN2NNY01ZeUFFSC81?= =?utf-8?B?TjdJNi9JYktGMzNnNitoK0NjRVBOV0dYaENSb3pETmJualRNT0tQTE9Xa0pI?= =?utf-8?B?M3RJR0xUU2JEaFRTbEhncXJHcWNrYmF4UGlrN2grQjcvYVJxM2l3ZUsxaVdq?= =?utf-8?B?MFYxUjBjNnBZcHN1U2VQR1owY3J3eUJ3Wkc5eHpFNWRULzNyT0MvQ3pwZ2xS?= =?utf-8?B?Q3VmUG5QY0dZTWFhSWdDTEJaakVPVGxkc3QyYkFSWXBpQ1UweEdwWThjTEF4?= =?utf-8?B?Ui9FR0tYM0tSTjZ0WlN2ZVoxSm9qdnFadkVDL0plREVxbmhkRlpRRklvc0N0?= =?utf-8?B?VXBQUWF6YWpxTkxxSithbGdDNDRLZGJIb09INEZEQzU5OW9DWXZVL2JpR3ov?= =?utf-8?B?bVd2bEFKeE14aisxckQxbWdPNEpJcmVkeEl2VmhqNCtxaUpGaFpvU3c5V01v?= =?utf-8?B?dno5VU9yNVJ2T2IyQ0RSYU04YUxkNHFGcUc5SzI2QWgwVTFYL3ZkaERsN0Jy?= =?utf-8?Q?Nnc8TiLVuHptZ+fGtYvsFCFtZqzrRwajcSSoHZG?= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB5226 Original-Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT059.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 18996fc4-5f76-4dce-69dc-08d9145f818f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WqToerXzyAVMpl1MP5cliQNLMxkKT79gFxUCLWSleV8KMozbfdEzOUlPTOS+UYS+xBtJiwTvjBeOia1dt5kH06/rBtvuFlLF5Hnrs1LNrrb0zafd7Ox7zqg0JSdhiNga1a6TGu68UdTMSnREfrd2SLJtdkjDMxO59XinQwlUau/95LHsRLSASjhU8FFri51WezGBG3rhwgP3UAipSaxTz3cGY9q4VwABfoij+xXkrueiekmfWC05iueA3QqBkf2PNc713U1Zpg+TeaIB41EkzmfRtrQga5Rj4l3zUaMZCV6kbzEmhd0s0OXJZuMlsARdvtnQTDetZd5MsQQ48A/ETYuT0THdWbHLP6LmdsaJd7xdGP+jkW9IL3QKl1vesYeVO2+Tb2a3+8crombLZyJCr5YyA1oEewD2S0RAv53zF5khWgsmTrLzMjlreEjvEZwyEcHmGjI8OXBToWXtJK6Sy4K/l00ZdxNEhdw9rviSU+O+z6crV6EfhR9/ZHLH6EN2azma4FhUWxODk9nnEnt0UifDoTc99cP3BK5XmfCFQx9yMPAWVYL6+dsf43uSGs1KbF6IbanBkrSmf54uRUhR8S1li7IrgWwZFRCAUAr42OIySJwDTe9Ia3+V0jGHZUm/2FVT8XgsXo8e8mF0u96TAq6Ho5OPWeFhvWnVZC9usyj2yTZzb4j8hyieho4KSAx7 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)(136003)(39850400004)(346002)(396003)(46966006)(36840700001)(53546011)(8886007)(2906002)(186003)(36756003)(235185007)(47076005)(8936002)(83380400001)(66616009)(16526019)(70206006)(44144004)(55016002)(6862004)(316002)(36860700001)(336012)(5660300002)(33964004)(86362001)(7696005)(82310400003)(82740400003)(70586007)(356005)(81166007)(956004)(2616005)(26005)(8676002)(33656002)(478600001)(4326008)(44832011)(1076003)(2700100001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2021 09:31:18.0839 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 61282578-81c9-4da9-9af6-08d9145f87ce 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: VE1EUR03FT059.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3536 X-Spam-Status: No, score=-13.7 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 09:31:28 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline The 05/10/2021 22:56, Carlos O'Donell wrote: > On 4/16/21 5:12 AM, Szabolcs Nagy via Libc-alpha wrote: > > The 04/15/2021 15:21, Adhemerval Zanella wrote: > >> On 13/04/2021 05:19, Szabolcs Nagy via Libc-alpha wrote: > >>> This is a follow up patch to the fix for bug 19329. This adds > >>> relaxed MO atomics to accesses that are racy, but relaxed MO is > >>> enough. > >> > >> Could you extend a bit why relaxed MO should be suffice? > > > > is it ok to change the commit message to: > > > > This is a follow up patch to the fix for bug 19329. This adds relaxed > > MO atomics to accesses that are racy, but relaxed MO is enough. > > Suggest: > > This is a follow up patch to the fix for bug 19329. This adds relaxed > MO atomics to accesses that were previously data races but are now > race conditions, and where relaxed MO is sufficient. > > > The racy accesses all follow the pattern that the write is behind the > > s/racy accesses/race conditions/g > > > dlopen lock, but a read can happen concurrently (e.g. during tls access) > > without holding the lock. For slotinfo entries the read value only > > matters if it reads from a synchronized write in dlopen or dlclose, > > otherwise the related dtv entry is not valid to access so it is fine to > > leave it in inconsistent state. Same for GL(dl_tls_max_dtv_idx) and > > s/it in/it in an/g > > s/Same/The same applies for/g > > > GL(dl_tls_generation), but there we rely on the read value being larger > > than the last written value that was synchronized. > > Do you mean to imply that the synchronized writes all increase the generation > counter, and so any out of order reads rely on the value to be increasing? yes, if the current thread is synchronized with a dlopen and reads GL(dl_tls_genertion) with relaxed MO then either the gen of the dlopened module is read or a larger value. So we can use relaxed MO value to see if the dtv needs update at tls access. (This is the difficult bit in fixing bug 19924: we can use relaxed MO because we update the dtv upto the gen of the module. slotinfo entries with larger gen are ignored, but if we want to update upto the global gen then we need additional synchronization.) > Suggested: > The same applies for GL(dl_tls_max_dtv_idx) and GL(dl_tls_generation), but > there the algorithm relies on the fact that the read of the last synchronized > write is an increasing value. Thanks for the review, i attached the fixed patch i plan to commit later today if there are no further comments. --h31gzZEtNLTqOjlF Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="0001-elf-Use-relaxed-atomics-for-racy-accesses-BZ-19329.patch" >From 2a65e592a753310334c1ded2841215fb9c6024f8 Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy Date: Wed, 30 Dec 2020 19:19:37 +0000 Subject: [PATCH] elf: Use relaxed atomics for racy accesses [BZ #19329] This is a follow up patch to the fix for bug 19329. This adds relaxed MO atomics to accesses that were previously data races but are now race conditions, and where relaxed MO is sufficient. The race conditions all follow the pattern that the write is behind the dlopen lock, but a read can happen concurrently (e.g. during tls access) without holding the lock. For slotinfo entries the read value only matters if it reads from a synchronized write in dlopen or dlclose, otherwise the related dtv entry is not valid to access so it is fine to leave it in an inconsistent state. The same applies for GL(dl_tls_max_dtv_idx) and GL(dl_tls_generation), but there the algorithm relies on the fact that the read of the last synchronized write is an increasing value. Reviewed-by: Adhemerval Zanella --- elf/dl-close.c | 20 +++++++++++++------- elf/dl-open.c | 5 ++++- elf/dl-tls.c | 31 +++++++++++++++++++++++-------- sysdeps/x86_64/dl-tls.c | 3 ++- 4 files changed, 42 insertions(+), 17 deletions(-) diff --git a/elf/dl-close.c b/elf/dl-close.c index c51becd06b..3720e47dd1 100644 --- a/elf/dl-close.c +++ b/elf/dl-close.c @@ -79,9 +79,10 @@ remove_slotinfo (size_t idx, struct dtv_slotinfo_list *listp, size_t disp, { assert (old_map->l_tls_modid == idx); - /* Mark the entry as unused. */ - listp->slotinfo[idx - disp].gen = GL(dl_tls_generation) + 1; - listp->slotinfo[idx - disp].map = NULL; + /* Mark the entry as unused. These can be read concurrently. */ + atomic_store_relaxed (&listp->slotinfo[idx - disp].gen, + GL(dl_tls_generation) + 1); + atomic_store_relaxed (&listp->slotinfo[idx - disp].map, NULL); } /* If this is not the last currently used entry no need to look @@ -96,8 +97,8 @@ remove_slotinfo (size_t idx, struct dtv_slotinfo_list *listp, size_t disp, if (listp->slotinfo[idx - disp].map != NULL) { - /* Found a new last used index. */ - GL(dl_tls_max_dtv_idx) = idx; + /* Found a new last used index. This can be read concurrently. */ + atomic_store_relaxed (&GL(dl_tls_max_dtv_idx), idx); return true; } } @@ -571,7 +572,9 @@ _dl_close_worker (struct link_map *map, bool force) GL(dl_tls_dtv_slotinfo_list), 0, imap->l_init_called)) /* All dynamically loaded modules with TLS are unloaded. */ - GL(dl_tls_max_dtv_idx) = GL(dl_tls_static_nelem); + /* Can be read concurrently. */ + atomic_store_relaxed (&GL(dl_tls_max_dtv_idx), + GL(dl_tls_static_nelem)); if (imap->l_tls_offset != NO_TLS_OFFSET && imap->l_tls_offset != FORCED_DYNAMIC_TLS_OFFSET) @@ -769,8 +772,11 @@ _dl_close_worker (struct link_map *map, bool force) /* If we removed any object which uses TLS bump the generation counter. */ if (any_tls) { - if (__glibc_unlikely (++GL(dl_tls_generation) == 0)) + size_t newgen = GL(dl_tls_generation) + 1; + if (__glibc_unlikely (newgen == 0)) _dl_fatal_printf ("TLS generation counter wrapped! Please report as described in "REPORT_BUGS_TO".\n"); + /* Can be read concurrently. */ + atomic_store_relaxed (&GL(dl_tls_generation), newgen); if (tls_free_end == GL(dl_tls_static_used)) GL(dl_tls_static_used) = tls_free_start; diff --git a/elf/dl-open.c b/elf/dl-open.c index 09f0df7d38..bb79ef00f1 100644 --- a/elf/dl-open.c +++ b/elf/dl-open.c @@ -395,9 +395,12 @@ update_tls_slotinfo (struct link_map *new) } } - if (__builtin_expect (++GL(dl_tls_generation) == 0, 0)) + size_t newgen = GL(dl_tls_generation) + 1; + if (__glibc_unlikely (newgen == 0)) _dl_fatal_printf (N_("\ TLS generation counter wrapped! Please report this.")); + /* Can be read concurrently. */ + atomic_store_relaxed (&GL(dl_tls_generation), newgen); /* We need a second pass for static tls data, because _dl_update_slotinfo must not be run while calls to diff --git a/elf/dl-tls.c b/elf/dl-tls.c index 94f3cdbae0..dc69cd984e 100644 --- a/elf/dl-tls.c +++ b/elf/dl-tls.c @@ -179,7 +179,9 @@ _dl_next_tls_modid (void) /* No gaps, allocate a new entry. */ nogaps: - result = ++GL(dl_tls_max_dtv_idx); + result = GL(dl_tls_max_dtv_idx) + 1; + /* Can be read concurrently. */ + atomic_store_relaxed (&GL(dl_tls_max_dtv_idx), result); } return result; @@ -363,10 +365,12 @@ allocate_dtv (void *result) dtv_t *dtv; size_t dtv_length; + /* Relaxed MO, because the dtv size is later rechecked, not relied on. */ + size_t max_modid = atomic_load_relaxed (&GL(dl_tls_max_dtv_idx)); /* We allocate a few more elements in the dtv than are needed for the initial set of modules. This should avoid in most cases expansions of the dtv. */ - dtv_length = GL(dl_tls_max_dtv_idx) + DTV_SURPLUS; + dtv_length = max_modid + DTV_SURPLUS; dtv = calloc (dtv_length + 2, sizeof (dtv_t)); if (dtv != NULL) { @@ -771,7 +775,7 @@ _dl_update_slotinfo (unsigned long int req_modid) if (modid > max_modid) break; - size_t gen = listp->slotinfo[cnt].gen; + size_t gen = atomic_load_relaxed (&listp->slotinfo[cnt].gen); if (gen > new_gen) /* Not relevant. */ @@ -783,7 +787,8 @@ _dl_update_slotinfo (unsigned long int req_modid) continue; /* If there is no map this means the entry is empty. */ - struct link_map *map = listp->slotinfo[cnt].map; + struct link_map *map + = atomic_load_relaxed (&listp->slotinfo[cnt].map); /* Check whether the current dtv array is large enough. */ if (dtv[-1].counter < modid) { @@ -927,7 +932,12 @@ __tls_get_addr (GET_ADDR_ARGS) { dtv_t *dtv = THREAD_DTV (); - if (__glibc_unlikely (dtv[0].counter != GL(dl_tls_generation))) + /* Update is needed if dtv[0].counter < the generation of the accessed + module. The global generation counter is used here as it is easier + to check. Synchronization for the relaxed MO access is guaranteed + by user code, see CONCURRENCY NOTES in _dl_update_slotinfo. */ + size_t gen = atomic_load_relaxed (&GL(dl_tls_generation)); + if (__glibc_unlikely (dtv[0].counter != gen)) return update_get_addr (GET_ADDR_PARAM); void *p = dtv[GET_ADDR_MODULE].pointer.val; @@ -950,7 +960,10 @@ _dl_tls_get_addr_soft (struct link_map *l) return NULL; dtv_t *dtv = THREAD_DTV (); - if (__glibc_unlikely (dtv[0].counter != GL(dl_tls_generation))) + /* This may be called without holding the GL(dl_load_lock). Reading + arbitrary gen value is fine since this is best effort code. */ + size_t gen = atomic_load_relaxed (&GL(dl_tls_generation)); + if (__glibc_unlikely (dtv[0].counter != gen)) { /* This thread's DTV is not completely current, but it might already cover this module. */ @@ -1036,8 +1049,10 @@ cannot create TLS data structures")); /* Add the information into the slotinfo data structure. */ if (do_add) { - listp->slotinfo[idx].map = l; - listp->slotinfo[idx].gen = GL(dl_tls_generation) + 1; + /* Can be read concurrently. See _dl_update_slotinfo. */ + atomic_store_relaxed (&listp->slotinfo[idx].map, l); + atomic_store_relaxed (&listp->slotinfo[idx].gen, + GL(dl_tls_generation) + 1); } } diff --git a/sysdeps/x86_64/dl-tls.c b/sysdeps/x86_64/dl-tls.c index 6595f6615b..24ef560b71 100644 --- a/sysdeps/x86_64/dl-tls.c +++ b/sysdeps/x86_64/dl-tls.c @@ -40,7 +40,8 @@ __tls_get_addr_slow (GET_ADDR_ARGS) { dtv_t *dtv = THREAD_DTV (); - if (__glibc_unlikely (dtv[0].counter != GL(dl_tls_generation))) + size_t gen = atomic_load_relaxed (&GL(dl_tls_generation)); + if (__glibc_unlikely (dtv[0].counter != gen)) return update_get_addr (GET_ADDR_PARAM); return tls_get_addr_tail (GET_ADDR_PARAM, dtv, NULL); -- 2.17.1 --h31gzZEtNLTqOjlF--