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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6F2273858D38 for ; Thu, 16 May 2024 12:29:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6F2273858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6F2273858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715862579; cv=none; b=xIboCnOrFCviNUPCt7twdMxgD1Ew+VPeSJHx2tFPhnXigCdwW7gcMrk6MO/nwKSP6SWSXQEgeGaXbtM57jxckNYajZeVeRFPn08OEoDIpxUxL+i2B5nP90bXWEVpVw6ZRc2EdAYW+qdWGR7BI5IAtewjZDHoxqn8RYhFBmd/x4I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715862579; c=relaxed/simple; bh=kgy5UlyMKJE2wOXvLPW/rko/JVXvVGbsWLuozssFPD4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xmut/ktKEmjQp119fsS2dksqBLgIYeDYGMciNs3rM8fFjgD/e2dldEs+m8QzvwhaL/tqi4rZ9d3Yj7x3HONgs0FT7BS0NlWVYdE+iEv/EP7trfcn65tgIBH4ddt9TvfVPIdr9UrRINo8hi6+GX/M54jpcU9+ydgRihC9bSvkRXI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715862577; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RHEHssJLusxuwCXpk9mO2e79ceIHr+jPo87j1cO5cxY=; b=NVgxrZCiE0zdikjLwMPtv9+F/yMKLUoJSMtTXo9QKS4TUOF0taKfNZ44Viq/fbmAxYRupx 7K4wAe3lt2pl104eScaXTp0n5b5rsNvYyI9KMxOSIUj2fQaC64cavgjGytc9dP5jZiagwU wFHtBFCrKxaD+nCj6WAec1vuEh6qLMo= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-230--VnbhMt_OhuKa4QpB43K2Q-1; Thu, 16 May 2024 08:29:33 -0400 X-MC-Unique: -VnbhMt_OhuKa4QpB43K2Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A68D01C05129; Thu, 16 May 2024 12:29:33 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 02E03C15BB9; Thu, 16 May 2024 12:29:32 +0000 (UTC) From: Florian Weimer To: Andreas Schwab Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v2] elf: Avoid re-initializing already allocated TLS in dlopen (bug 31717) In-Reply-To: (Andreas Schwab's message of "Wed, 15 May 2024 16:44:18 +0200") References: <87y18duhgl.fsf@oldenburg.str.redhat.com> Date: Thu, 16 May 2024 14:29:31 +0200 Message-ID: <87le4andn8.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Andreas Schwab: > On Mai 14 2024, Florian Weimer wrote: > >> + If DO_ADD is true and the return value is true, the TLS generation >> + counter must be incremented afterwards, by calling >> + _dl_update_slotinfo. */ > > This is confusing. The only uses that check the return value call it > with !DO_ADD. I'll assume this is criticism of the description, not the interface itself. What about this? /* Add module to slot information data. If DO_ADD is false, only the required memory is allocated. Must be called with GL (dl_load_tls_lock) acquired. If the function has already been called for the link map L with !DO_ADD, then this function will not raise an exception, otherwise it is possible that it encounters a memory allocation failure. Return false if L has already been added to the slotinfo data, or if L has no TLS data. If the returned value is true, L has been added with this call (DO_ADD), or has been added in a previous call (!DO_ADD). The expected usage is as follows: Call _dl_add_to_slotinfo for several link maps with DO_ADD set to false, and record if any calls result in a true result. If there was a true result, call _dl_add_to_slotinfo again, this time with DO_ADD set to true. (For simplicity, it's possible to call the function for link maps where the previous result was false.) The return value from the second round of calls can be ignored. If there was true result initially, call _dl_update_slotinfo to update the TLS generation counter. */ extern bool _dl_add_to_slotinfo (struct link_map *l, bool do_add) attribute_hidden; Thanks, Florian