From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43394 invoked by alias); 20 Nov 2019 12:50:35 -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 43379 invoked by uid 89); 20 Nov 2019 12:50:35 -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=-18.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy= X-Spam-Status: No, score=-18.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS 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: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2019 12:50:33 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 8692B30014AB; Wed, 20 Nov 2019 13:50:31 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id EEAAC413CEAA; Wed, 20 Nov 2019 13:50:25 +0100 (CET) Message-ID: Subject: Re: patch 1/2 debuginfod client From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org, amerey@redhat.com Date: Wed, 20 Nov 2019 12:50:00 -0000 In-Reply-To: <20191119212211.GG4911@redhat.com> References: <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> <20191119162034.GC4911@redhat.com> <20191119201520.GB3494@wildebeest.org> <20191119212211.GG4911@redhat.com> Content-Type: multipart/mixed; boundary="=-N/iLhhYsesPGXk0lTzOb" X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00191.txt.bz2 --=-N/iLhhYsesPGXk0lTzOb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-length: 2255 Hi, On Tue, 2019-11-19 at 16:22 -0500, Frank Ch. Eigler wrote: > On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote: > > > 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. > >=20 > > But the warning isn't about multiple initialization. It is about > > initialization when other threads are running that might be using any > > of the libcurl support libraries. >=20 > Since 2001, the curl_global_init function does nothing to interfere > with any libcurl activity, if the library is already initialized. Any > call to the normal libcurl functions first calls this function. I > guess I just fail to see a plausible problem scenario short of a > minuscule race over incrementing an initialization counter, which is a > race that every other libcurl user has accepted. But it isn't just about interference with other libcurl activity. If you look at the curl_global_init code you see that it actually calls a lot of code in other libraries. It is the curl_global_init code that shouldn't be run in a multi-threaded environment. That it is acceptable to others doesn't immediately make it safe to use in our case. We are slowly trying to make libdw.so into a multi-tread safe library and do expect it to be used in multi-threaded code. We aren't fully there yet. But it would be a shame to introduce more issues if we can prevent it. > > > > That is why I think doing the dlopen of libdebuginfod.so eagerly fr= om a > > > > libdw.so constructor function or _init might be necessary to make s= ure > > > > no other threads are running yet. > > >=20 > > > 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. > >=20 > > It could, but I think that would be unlikely. We can at least document > > that it is unsafe to use libdw.so with dlopen. But if it is done, > > could we detect it and not do the loading of libdebuginfod.so in that > > case? >=20 > I don't know how to do that. I assume you mean the second part. The attached is what I would propose for the first part. Do you think that is a bad idea? Thanks, Mark --=-N/iLhhYsesPGXk0lTzOb Content-Disposition: inline; filename="debuginfod-client-dwfl-early-init.patch" Content-Type: text/x-patch; name="debuginfod-client-dwfl-early-init.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 Content-length: 3477 ZGlmZiAtLWdpdCBhL2xpYmR3ZmwvZGVidWdpbmZvZC1jbGllbnQuYyBiL2xp YmR3ZmwvZGVidWdpbmZvZC1jbGllbnQuYwppbmRleCAzN2E0YzcxZi4uZWU2 MDRhZDkgMTAwNjQ0Ci0tLSBhL2xpYmR3ZmwvZGVidWdpbmZvZC1jbGllbnQu YworKysgYi9saWJkd2ZsL2RlYnVnaW5mb2QtY2xpZW50LmMKQEAgLTQ2LDMy ICs0Niw3IEBAIGdldF9jbGllbnQgKER3ZmwgKmR3ZmwpCiAgIGlmIChkd2Zs LT5kZWJ1Z2luZm9kICE9IE5VTEwpCiAgICAgcmV0dXJuIGR3ZmwtPmRlYnVn aW5mb2Q7CiAKLSAgaWYgKGZwX2RlYnVnaW5mb2RfYmVnaW4gPT0gTlVMTCkK LSAgICB7Ci0gICAgICB2b2lkICpkZWJ1Z2luZm9kX3NvID0gZGxvcGVuKCJs aWJkZWJ1Z2luZm9kLSIgVkVSU0lPTiAiLnNvIiwgUlRMRF9MQVpZKTsKLQot ICAgICAgaWYgKGRlYnVnaW5mb2Rfc28gPT0gTlVMTCkKLQlkZWJ1Z2luZm9k X3NvID0gZGxvcGVuKCJsaWJkZWJ1Z2luZm9kLnNvIiwgUlRMRF9MQVpZKTsK LQotICAgICAgaWYgKGRlYnVnaW5mb2Rfc28gIT0gTlVMTCkKLQl7Ci0JICBm cF9kZWJ1Z2luZm9kX2JlZ2luID0gZGxzeW0gKGRlYnVnaW5mb2Rfc28sICJk ZWJ1Z2luZm9kX2JlZ2luIik7Ci0JICBmcF9kZWJ1Z2luZm9kX2ZpbmRfZXhl Y3V0YWJsZSA9IGRsc3ltIChkZWJ1Z2luZm9kX3NvLAotCQkJCQkJICJkZWJ1 Z2luZm9kX2ZpbmRfZXhlY3V0YWJsZSIpOwotCSAgZnBfZGVidWdpbmZvZF9m aW5kX2RlYnVnaW5mbyA9IGRsc3ltIChkZWJ1Z2luZm9kX3NvLAotCQkJCQkJ ImRlYnVnaW5mb2RfZmluZF9kZWJ1Z2luZm8iKTsKLQkgIGZwX2RlYnVnaW5m b2RfZW5kID0gZGxzeW0gKGRlYnVnaW5mb2Rfc28sICJkZWJ1Z2luZm9kX2Vu ZCIpOwotCX0KLQotICAgICAgaWYgKGZwX2RlYnVnaW5mb2RfYmVnaW4gPT0g TlVMTAotCSAgfHwgZnBfZGVidWdpbmZvZF9maW5kX2V4ZWN1dGFibGUgPT0g TlVMTAotCSAgfHwgZnBfZGVidWdpbmZvZF9maW5kX2RlYnVnaW5mbyA9PSBO VUxMCi0JICB8fCBmcF9kZWJ1Z2luZm9kX2VuZCA9PSBOVUxMKQotCWZwX2Rl YnVnaW5mb2RfYmVnaW4gPSAodm9pZCAqKSAtMTsgLyogbmV2ZXIgdHJ5IGFn YWluICovCi0gICAgfQotCi0gIGlmIChmcF9kZWJ1Z2luZm9kX2JlZ2luICE9 IE5VTEwKLSAgICAgICYmIGZwX2RlYnVnaW5mb2RfYmVnaW4gIT0gKHZvaWQg KikgLTEpCisgIGlmIChmcF9kZWJ1Z2luZm9kX2JlZ2luICE9IE5VTEwpCiAg ICAgewogICAgICAgZHdmbC0+ZGVidWdpbmZvZCA9ICgqZnBfZGVidWdpbmZv ZF9iZWdpbikgKCk7CiAgICAgICByZXR1cm4gZHdmbC0+ZGVidWdpbmZvZDsK QEAgLTEyMCwzICs5NSwzNyBAQCBfX2xpYmR3ZmxfZGVidWdpbmZvZF9lbmQg KGRlYnVnaW5mb2RfY2xpZW50ICpjKQogICBpZiAoYyAhPSBOVUxMKQogICAg ICgqZnBfZGVidWdpbmZvZF9lbmQpIChjKTsKIH0KKworLyogVHJ5IHRvIGdl dCB0aGUgbGliZGVidWdpbmZvZCBsaWJyYXJ5IGZ1bmN0aW9ucyB0byBtYWtl IHN1cmUKKyAgIGV2ZXJ5dGhpbmcgaXMgaW5pdGlhbGl6ZWQgZWFybHkuICAq Lwordm9pZCBfX2F0dHJpYnV0ZV9fICgoY29uc3RydWN0b3IpKQorX19saWJk d2ZsX2RlYnVnaW5mb2RfaW5pdCAodm9pZCkKK3sKKyAgdm9pZCAqZGVidWdp bmZvZF9zbyA9IGRsb3BlbigibGliZGVidWdpbmZvZC0iIFZFUlNJT04gIi5z byIsIFJUTERfTEFaWSk7CisKKyAgaWYgKGRlYnVnaW5mb2Rfc28gPT0gTlVM TCkKKyAgICBkZWJ1Z2luZm9kX3NvID0gZGxvcGVuKCJsaWJkZWJ1Z2luZm9k LnNvIiwgUlRMRF9MQVpZKTsKKworICBpZiAoZGVidWdpbmZvZF9zbyAhPSBO VUxMKQorICAgIHsKKyAgICAgIGZwX2RlYnVnaW5mb2RfYmVnaW4gPSBkbHN5 bSAoZGVidWdpbmZvZF9zbywgImRlYnVnaW5mb2RfYmVnaW4iKTsKKyAgICAg IGZwX2RlYnVnaW5mb2RfZmluZF9leGVjdXRhYmxlID0gZGxzeW0gKGRlYnVn aW5mb2Rfc28sCisJCQkJCSAgICAgImRlYnVnaW5mb2RfZmluZF9leGVjdXRh YmxlIik7CisgICAgICBmcF9kZWJ1Z2luZm9kX2ZpbmRfZGVidWdpbmZvID0g ZGxzeW0gKGRlYnVnaW5mb2Rfc28sCisJCQkJCSAgICAiZGVidWdpbmZvZF9m aW5kX2RlYnVnaW5mbyIpOworICAgICAgZnBfZGVidWdpbmZvZF9lbmQgPSBk bHN5bSAoZGVidWdpbmZvZF9zbywgImRlYnVnaW5mb2RfZW5kIik7CisKKyAg ICAgIC8qIFdlIGVpdGhlciBnZXQgdGhlbSBhbGwsIG9yIHdlIGdldCBub25l LiAgKi8KKyAgICAgIGlmIChmcF9kZWJ1Z2luZm9kX2JlZ2luID09IE5VTEwK KwkgIHx8IGZwX2RlYnVnaW5mb2RfZmluZF9leGVjdXRhYmxlID09IE5VTEwK KwkgIHx8IGZwX2RlYnVnaW5mb2RfZmluZF9kZWJ1Z2luZm8gPT0gTlVMTAor CSAgfHwgZnBfZGVidWdpbmZvZF9lbmQgPT0gTlVMTCkKKwl7CisJICBmcF9k ZWJ1Z2luZm9kX2JlZ2luID0gTlVMTDsKKwkgIGZwX2RlYnVnaW5mb2RfZmlu ZF9leGVjdXRhYmxlID0gTlVMTDsKKwkgIGZwX2RlYnVnaW5mb2RfZmluZF9k ZWJ1Z2luZm8gPSBOVUxMOworCSAgZnBfZGVidWdpbmZvZF9lbmQgPSBOVUxM OworCSAgZGxjbG9zZSAoZGVidWdpbmZvZF9zbyk7CisJfQorICAgIH0KK30K --=-N/iLhhYsesPGXk0lTzOb--