From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by sourceware.org (Postfix) with ESMTPS id 37F68385DC33 for ; Thu, 24 Jun 2021 12:57:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37F68385DC33 Received: by mail-qv1-xf31.google.com with SMTP id y4so3193573qvs.10 for ; Thu, 24 Jun 2021 05:57:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mazOTwKgJNHF8xHd5onGAK/seHingZZSh1vb53NCEdA=; b=U/o1ax7xTuBRiz+kukK/NgfI86Rdr4WE3x3655/6/y4HU4fc71t+Hcgc/JmsD98kY9 4+iqeO2pdnsnI1s4tpwpzdkxT4c9abq1H/Zgtb+3LwiZqQd6NgoiPZ0VfIXlnSlqRlml f/yGh6Vv6qSYIWid2T2dHDThGGeyxPCOnDHZ9hCWHA/AxJNJNxL1SP0tgdBexXfn+AsP GXtu/nrzm0wIVSixee5y7rblbDrv2ky1Jlh/SfEcbim3PiCScEQCKGblNUUsSO5EHOjT dU9Jw7TBywbjvr6jU0I9iU703jHilLah3mQ/o3wnkQByJ7m923friy95wKbe1NjzUJF/ jgeQ== X-Gm-Message-State: AOAM533ydTZ2wQy9AtI6AwdQvXEzk8NTTOdgAwmqO7qT/Bmfz3COGzxG Ki+P6fKzls4FDh3KIQUlvOwOvG1wmJmFpw== X-Google-Smtp-Source: ABdhPJzm8Tp1iZ6oasV6MpMV0ggKP4m6SCguQPKuyLc1/1wmd9nID1yLpyZAiLEM3o4El/84bXcOog== X-Received: by 2002:a0c:eb0c:: with SMTP id j12mr5231139qvp.3.1624539444732; Thu, 24 Jun 2021 05:57:24 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id y137sm2552995qkb.27.2021.06.24.05.57.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Jun 2021 05:57:24 -0700 (PDT) Subject: Re: [PATCH v2 08/14] elf: Fix DTV gap reuse logic [BZ #27135] To: libc-alpha@sourceware.org References: <299d28c6695cd2e76f222b0d36b17b7124c549e7.1618301209.git.szabolcs.nagy@arm.com> <878s2zlhjp.fsf@oldenburg.str.redhat.com> <87v963jvlf.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <04586c1a-60b4-7aaa-30ed-3482fdc7162c@linaro.org> Date: Thu, 24 Jun 2021 09:57:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87v963jvlf.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 12:57:26 -0000 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?