From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 1F5E639874C3 for ; Thu, 8 Jul 2021 13:34:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F5E639874C3 Received: by mail-pf1-x431.google.com with SMTP id y4so5429889pfi.9 for ; Thu, 08 Jul 2021 06:34:48 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qSB3UWkkw2XQT/TwGvRPK2v2I+pNqKsih6ocw/AT3M8=; b=Op/pTZrg+GiVeU5pRiRpAWHk4iAPOQZpIrH/CG8Cy8+SbdITT4MsvgMzfuazc/vif+ nV1eYOOmta1A736sxBi48DGbyYKjv0dcO5UhTeQ1rYAGBYFQ9KUofi+H67PZTzoGNsfI ckCSX8t+HKmgMJ9PSD6dR5CYknK2aBZoMea+PI1k1ClcuywQJ70YGR6ThoMrsZD90lGD I6P6L3sbNtwwdrnznWZiuLGxTgIkkQtGcMBeY469fhb4/4TGPqVYwscFDMvMWf2BX5xP SILdEpLXTbKivvZFztjTEjT+LyVcqYXRH1YOSPo+PfZA783QVbm6sAPQlEg98EEJOt8n S0nA== X-Gm-Message-State: AOAM533ECnh7UFZNhj+nGw1UrGGmZun1Y8ayDcV+ya4zdUrAmIFMYAM5 YdmCUwK2EGdmZqNc+BNx1tKBzw== X-Google-Smtp-Source: ABdhPJzrFl5tPXcsHWIn3hWkSWW67ADVR941f61wFY0X9/9sq79yQ02DjJG56J3YVjXsNhbLQN/sFg== X-Received: by 2002:a63:5b02:: with SMTP id p2mr32097042pgb.161.1625751286999; Thu, 08 Jul 2021 06:34:46 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id y10sm2634307pjy.18.2021.07.08.06.34.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jul 2021 06:34:46 -0700 (PDT) Subject: Re: [PATCH] elf: Fix DTV gap reuse logic (BZ #27135) To: Szabolcs Nagy Cc: Florian Weimer , libc-alpha@sourceware.org, Carlos O'Donell References: <20210628180358.235038-1-adhemerval.zanella@linaro.org> <87czrtz6no.fsf@oldenburg.str.redhat.com> <20210708110012.GQ14854@arm.com> <5113517e-65ec-2b7e-2c80-97f2900448d4@linaro.org> <20210708130408.GR14854@arm.com> From: Adhemerval Zanella Message-ID: <1bbaaab0-95f7-2fd3-590d-a8c52e306145@linaro.org> Date: Thu, 8 Jul 2021 10:34:43 -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: <20210708130408.GR14854@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 08 Jul 2021 13:34:50 -0000 On 08/07/2021 10:04, Szabolcs Nagy wrote: > The 07/08/2021 09:20, Adhemerval Zanella wrote: >> >> >> On 08/07/2021 08:00, Szabolcs Nagy wrote: >>> The 07/08/2021 08:00, Florian Weimer wrote: >>>> * Adhemerval Zanella: >>>>> diff --git a/elf/dl-tls.c b/elf/dl-tls.c >>>>> index 2b5161d10a..4ec4c7f38c 100644 >>>>> --- a/elf/dl-tls.c >>>>> +++ b/elf/dl-tls.c >>>>> @@ -157,7 +157,11 @@ _dl_next_tls_modid (void) >>>>> } >>>>> >>>>> if (result - disp < runp->len) >>>>> - break; >>>>> + { >>>>> + /* Mark the entry as used, so any dependency see it. */ >>>>> + runp->slotinfo[result - disp].map = (struct link_map *) -1; >>>>> + break; >>>>> + } >>>>> >>>>> disp += runp->len; >>>>> } >>>> >>>> Which dependency? >> >> Any shared library dependency being loaded after this. >> >>>> >>>> I think the special value -1 needs to be documented on the slotinfo >>>> struct member. >>>> >>>> When Carlos and I discussed this, we couldn't quite decide whether it >>>> was appropriate just to assign the actual link map value here. >>> >>> slotinfo[].map is only accessed without locks during >>> _dl_update_slotinfo at tls access and then it is >>> only used to get the map for the module in which >>> tls is accessed. (and to skip NULL maps when resizing >>> dtv but that's just a minor optimization). >>> >>> so the only concurrent .map access does not really >>> care about its value for an incomplete module. >>> >>> so we only need to reason locally what happens within >>> one dlopen call to decide what can be put temporarily >>> in .map and the final value only has to be stored >>> before the lock is released. (with bug 19924 fixed >>> the final .map and .gen values likely have to be >>> stored a bit earlier: before the global gen count is >>> updated) >>> >>> the tricky bit is to check if the slotinfo state is >>> rolled back right in case of dlopen failures. but it >>> seems to me that modid assignment happens after the >>> point where failures are handled via dlclose which >>> will fixup the slotinfo state (i.e. after unlock >>> unused slotinfo entries are marked with .map == NULL). >> >> That is my understanding as well and I tried to check if the >> rollback is correctly done by adding more cases on the >> tst-tls20.c. >> >>> >>> so i think _dl_next_tls_modid() can be changed to >>> _dl_assign_tls_modid(map) which writes map to the >>> slotinfo .map. >> What do you mean by '_dl_assign_tls_modid()' in this case ? > > currently the only use is > > map->l_tls_modid = _dl_next_tls_modid (); > > which can be changed to > > _dl_assign_tls_modid (map); > > which sets map->l_tls_modid as well as slotinfo[i].map = map > marking the slotinfo entry non-free (with relaxed atomic > store since it can be read concurrently). > > i don't know if 'assign' is the right word, but the point is > that we don't just get the next modid, but allocate it too > for the given map. I see, this should work since we just need either a sentinel value or a valid link_map to indicate that the slot is being already taken. For the rollback in case of failure remove_slotinfo() should handle it (it just check for non NULL). I will send an updated patch.