From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11099 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Reviving planned ldso changes Date: Sat, 4 Mar 2017 11:58:18 +0100 Message-ID: <20170304105817.GF2082@port70.net> References: <20170104193627.GO1555@brightrain.aerifal.cx> <587A988A.50105@Wilcox-Tech.com> <20170115174438.GD1533@brightrain.aerifal.cx> <20170226010429.GQ12395@port70.net> <20170226013926.GY1520@brightrain.aerifal.cx> <20170226102830.GR12395@port70.net> <20170226152016.GZ1520@brightrain.aerifal.cx> <20170226153436.GA2082@port70.net> <20170226213925.GB1520@brightrain.aerifal.cx> <20170303013026.GJ1520@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1488625115 14042 195.159.176.226 (4 Mar 2017 10:58:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 10:58:35 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: musl@lists.openwall.com Original-X-From: musl-return-11114-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 04 11:58:30 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ck7ON-00031u-2q for gllmg-musl@m.gmane.org; Sat, 04 Mar 2017 11:58:27 +0100 Original-Received: (qmail 17982 invoked by uid 550); 4 Mar 2017 10:58:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17964 invoked from network); 4 Mar 2017 10:58:29 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20170303013026.GJ1520@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11099 Archived-At: * Rich Felker [2017-03-02 20:30:26 -0500]: > Here's a v4 of the patch that saves the "init parent" we descended > from so that it can return where it left off. There are a couple > gratuitous hunks left over adding setting of "needed_by" where it made > sense to be set, but it's not actually used anymore. They could be > dropped if desired but are probably nice to keep for the sake of > consistency of data, even thoough it's data we don't use. > > I believe this can be extended to allow concurrent dlopen by amending > the case in the tree-walk where a dependency isn't constructed yet but > already has an "init parent" to check whether it's > pending-construction in the calling thread (recursive dlopen from a > ctor) or another thread; in the former case (as now) treat it as > already-constructed; in the latter, wait on a condvar that gets > signaled at the end of each construction, then continue the loop > without advancing p. There are probably some subtleties I'm missing, > though. ... > static void do_init_fini(struct dso *p) > { > size_t dyn[DYN_CNT]; > - int need_locking = libc.threads_minus_1; > - /* Allow recursive calls that arise when a library calls > - * dlopen from one of its constructors, but block any > - * other threads until all ctors have finished. */ > - if (need_locking) pthread_mutex_lock(&init_fini_lock); > - for (; p; p=p->prev) { > - if (p->constructed) continue; > + pthread_mutex_lock(&init_fini_lock); > + /* Construct in dependency order without any recursive state. */ > + while (p && !p->constructed) { > + /* The following loop descends into the first dependency > + * that is neither alredy constructed nor pending > + * construction due to circular deps, stopping only > + * when it reaches a dso with no remaining dependencies > + * to descend into. */ > + while (p->deps && p->deps[p->next_dep]) { > + if (!p->deps[p->next_dep]->constructed && > + !p->deps[p->next_dep]->init_parent) { > + p->deps[p->next_dep]->init_parent = p; > + p = p->deps[p->next_dep++]; i think the root may be visited twice because it has no init_parent, which may be problematic with the concurrent dlopen (and can cause unexpected ctor order: the root node is not constructed last if there is a cycle through it) i think only checking init_parent of a dep is enough and the root node can have a dummy parent that is guaranteed to be not a dependency (ldso?) and constructed so it stops the loop. > + } else { > + p->next_dep++; > + } > + } > p->constructed = 1; > decode_vec(p->dynv, dyn, DYN_CNT); > if (dyn[0] & ((1< @@ -1233,17 +1248,19 @@ static void do_init_fini(struct dso *p) > size_t *fn = laddr(p, dyn[DT_INIT_ARRAY]); > while (n--) ((void (*)(void))*fn++)(); > } > - if (!need_locking && libc.threads_minus_1) { > - need_locking = 1; > - pthread_mutex_lock(&init_fini_lock); > - } > - } > - if (need_locking) pthread_mutex_unlock(&init_fini_lock); > + /* Revisit "parent" dso which caused the just-constructed > + * dso to be pulled in as a dependency. On the next loop > + * iteration we will either descend to construct a sibling > + * of the just-constructed dso, or finish constructing the > + * parent if no unfinished deps remain. */ > + p = p->init_parent; > + } > + pthread_mutex_unlock(&init_fini_lock); > }