From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 525E53857C66 for ; Thu, 24 Jun 2021 14:20:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 525E53857C66 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-421-UtDNPx7DNrS7fYO4rsAw8Q-1; Thu, 24 Jun 2021 10:20:26 -0400 X-MC-Unique: UtDNPx7DNrS7fYO4rsAw8Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6F8158042F3; Thu, 24 Jun 2021 14:20:25 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-228.ams2.redhat.com [10.36.112.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8FC0E60C05; Thu, 24 Jun 2021 14:20:24 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH v2 08/14] elf: Fix DTV gap reuse logic [BZ #27135] References: <299d28c6695cd2e76f222b0d36b17b7124c549e7.1618301209.git.szabolcs.nagy@arm.com> <878s2zlhjp.fsf@oldenburg.str.redhat.com> <87v963jvlf.fsf@oldenburg.str.redhat.com> <04586c1a-60b4-7aaa-30ed-3482fdc7162c@linaro.org> Date: Thu, 24 Jun 2021 16:20:22 +0200 In-Reply-To: <04586c1a-60b4-7aaa-30ed-3482fdc7162c@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Thu, 24 Jun 2021 09:57:22 -0300") Message-ID: <87r1grjqe1.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP 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: Thu, 24 Jun 2021 14:20:29 -0000 * 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: >>> >>> >>> >>> 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