From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10535 invoked by alias); 19 Nov 2019 16:20:42 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 10523 invoked by uid 89); 19 Nov 2019 16:20:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1384 X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Nov 2019 16:20:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574180439; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xeNRDjYz0vJUuocnEUxQJ3airkwTVcdi0F2ixIWpc88=; b=CLQpYN0IZXOYt6/sR8UHB7RUZnKvT1S6xFKrqlTA3OLvwnUUo+VejM0Gee8ScAsHCMmmgi RVRKc9KGRIhVhAl46PrD7B1baxmAsuulDoVqi3t11hlMQncFjYgmF01ygrW91LtUxRUoM0 Rh2XMuc0Wbt1gluNuA1VBY80QjF99k8= 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-149-hBZQkU4mOf6pJeDPmL1iog-1; Tue, 19 Nov 2019 11:20:38 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1B2EF477; Tue, 19 Nov 2019 16:20:36 +0000 (UTC) Received: from redhat.com (ovpn-116-19.phx2.redhat.com [10.3.116.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F028863620; Tue, 19 Nov 2019 16:20:35 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92) (envelope-from ) id 1iX6F0-0002em-9M; Tue, 19 Nov 2019 11:20:34 -0500 Date: Tue, 19 Nov 2019 16:20:00 -0000 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org, amerey@redhat.com Subject: Re: patch 1/2 debuginfod client Message-ID: <20191119162034.GC4911@redhat.com> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <9bc154bce6389be9b07f2db9dcdcc605ad4f39e3.camel@klomp.org> <20191113232456.GA31583@redhat.com> <6d7430368a18c943f72bc3583efeafb2c192516f.camel@klomp.org> <20191116185256.GB19543@redhat.com> <356e88e4937ddb97a3e7cc93dbdfe29239ff960e.camel@klomp.org> <20191118203324.GD2880@redhat.com> <7ca3cc662684459fe21801344f0899f5108a8a70.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <7ca3cc662684459fe21801344f0899f5108a8a70.camel@klomp.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: hBZQkU4mOf6pJeDPmL1iog-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00183.txt.bz2 Hi - > > Doing a redundant initialization later is not a problem; there is a > > counter in there. The problematic case would be > > - a multithreaded application > > - loading debuginfod.so multiply concurrently somehow > > - and calling the solib ctor concurrently somehow > > - and all of this concurrently enough to defeat libcurl's init-counter > >=20 > > IMHO, not worth worrying about. Someday libcurl will do the right > > thing (tm) and plop this initialization into their solib ctor. >=20 > I do worry about this because any multi-threaded app that uses libdw.so > might cause trouble because we dlopen libdebuginfod.so lazily and then > it will call curl_global_init () which explicitly says: >=20 > This function is not thread safe. You must not call it when any > other thread in the program (i.e. a thread sharing the same memory) > is running. [...] That's what the doc says. What the code does, as far back as the year 2001, is have a static flag/counter in curl_global_init() that prevents multiple initialization. > That is why I think doing the dlopen of libdebuginfod.so eagerly from a > libdw.so constructor function or _init might be necessary to make sure > no other threads are running yet. That's not even enough for "sure" - if we're so deep in the hypotheticals hole, an application could be dlopen()ing libdw.so itself. - FChE