From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3353 invoked by alias); 3 Jan 2014 02:07:01 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 3334 invoked by uid 89); 3 Jan 2014 02:07:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 03 Jan 2014 02:07:00 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1CBEC33F66B; Fri, 3 Jan 2014 02:06:58 +0000 (UTC) From: Mike Frysinger To: =?utf-8?q?Ond=C5=99ej_B=C3=ADlka?= Subject: Re: [RFC][BZ #1874] Fix assertion triggered by thread/fork interaction Date: Fri, 03 Jan 2014 02:07:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.12.1; KDE/4.6.5; x86_64; ; ) Cc: libc-alpha@sourceware.org, libc-ports@sourceware.org References: <20131009200534.GA4300@domone.podge> <201401021718.23793.vapier@gentoo.org> <20140102235440.GB5026@domone> In-Reply-To: <20140102235440.GB5026@domone> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2347692.bJEtmTUFn7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401022107.03048.vapier@gentoo.org> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00012.txt.bz2 --nextPart2347692.bJEtmTUFn7 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 2217 On Thursday 02 January 2014 18:54:40 Ond=C5=99ej B=C3=ADlka wrote: > On Thu, Jan 02, 2014 at 05:18:22PM -0500, Mike Frysinger wrote: > > On Wednesday 09 October 2013 16:05:34 Ond=C5=99ej B=C3=ADlka wrote: > > > Details: > > >=20 > > > If a thread happens to hold dl_load_lock and have r_state set to RT_A= DD > > > or RT_DELETE at the time another thread calls fork(), then the child > > > exit code from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our > > > case) re-initializes dl_load_lock but does not restore r_state to > > > RT_CONSISTENT. If the child subsequently requires ld.so functionality > > > before calling exec(), then the assertion will fire. > > >=20 > > > The patch acquires dl_load_lock on entry to fork() and releases it on > > > exit from the parent path. The child path is initialized as currently > > > done. This is essentially pthreads_atfork, but forced to be first > > > because the acquisition of dl_load_lock must happen before > > > malloc_atfork is active to avoid a deadlock. > > > " > >=20 > > doesn't seem right that we grab the lock and then just reset it in the > > child ? seems like you should just unlock it rather than reset it in the > > child. >=20 > That part looks ok as without locking you could get inconsistent linker > structures. that's not what i meant. rather than make the call to reset in the child a= s=20 the code in the tree does now, if you grab the lock early, why not use the= =20 normal unlock call in the child ? struct state would be fine. > > i'm also wary of code that already grabs a lot of locks trying to grab > > even more. the code paths that already grab the IO locks ... can they > > possibly grab this one too ? like a custom format handler that triggers > > loading of libs ? >=20 > Do you haave a better solution? I send this to decide what to do with > this bug. I would not be surprised if we decided that it is invalid as > threads with fork cause problems in general. i think we want to support it without it being completely terrible. maybe the answer here is to reset all the dl state like we do with the lock= ?=20=20 is there some init func we could call ? i'm really not familiar with glibc= =20 ldso internals. -mike --nextPart2347692.bJEtmTUFn7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJSxhtGAAoJEEFjO5/oN/WB8uUQAMhGt3Txxuogl3zVeZXyskap uUos37fSqXI6x5xQUVAXfjRUWFcb0biHPXGWbKSyXZHAz/hCT4X2f+aEApJKSbwi krSto4l63Nq/9ZAdYOsRjy2CJgu0OrP8w3Wr267s//Lc0tpYjCbW921iuw25zX9t 9tiJYeSlJjWW7q/XapasHBZOLs4EdZnb+l5G565zE1Gnh0wruVf4rWG83sk+p1RC HM8TvKGH0x8vLKdYTKXKauQrxz3wgiuPyUNAbmSHMSK46oiTo7ZPUIaq/hrx1G0T abi1OwliPY/SuH7MArHs1LtRZP3wLT8qQKgEZsaASv949B1S88mXFE1uJwBvYpNB MO1wE4EK45XNna1ILBqdCjJgb/TSXFD5Zjlhn3pLroIQkpl1eu5O5+/EDfR72fVM mFOnfxwlvxanRgzy5naP8l2TE5B7rcZtq874rwWxdyS/Rg+L/7SyaXL5bmRhzwXU 0fqPTSRN0WrK4tKBK6wywuRtWXQ0w072NXatdmNWcOs6T2GrR5iE9GY5ZqVpyy0z kAfmM/85fdHt8TjOCE0vRUZv0WqV8WFjhjAYYBnkezGmJCjPgIdgCSZfjHcKu/4e ruIi7Y3ajrESvXUEFsR+CyK42lgSv2f8CmRSOGIT9liEQO5jwPTIc4wusKjuuUe+ 2pMZsdsVTQBBOXSGpxM0 =HrVN -----END PGP SIGNATURE----- --nextPart2347692.bJEtmTUFn7--