From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Adhemerval Zanella Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 3/3] Refactor atfork handlers Date: Fri, 23 Feb 2018 09:10:32 -0300 Message-ID: <84558035-c0a9-c83f-382c-ec7f87955a21@linaro.org> References: <1518008967-8310-1-git-send-email-adhemerval.zanella@linaro.org> <1518008967-8310-3-git-send-email-adhemerval.zanella@linaro.org> <88a58530-092d-4daa-1096-97a1bf8e08ff@redhat.com> <7b71dd04-afd0-9ff0-79c3-3d47cbd77ee2@redhat.com> <4aad8145-b06f-4d95-315a-73d5f2253971@linaro.org> <9d8251a8-7604-9846-ebde-409786e2ebf4@redhat.com> <780cefa6-543f-1a04-4b4e-9059a30d211b@linaro.org> <2fc18517-d23d-a298-e458-88ceff1cfc33@linaro.org> <9a266bea-818d-64da-198e-64f1c19a7915@redhat.com> <6d6bc007-7418-4667-bf2f-0ba2256cdbec@linaro.org> <6e23cc90-c734-3261-f89d-de9b83bb0a6b@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1519387723 7650 195.159.176.226 (23 Feb 2018 12:08:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Feb 2018 12:08:43 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: libc-alpha@sourceware.org To: Florian Weimer Original-X-From: libc-alpha-return-90529-glibc-alpha=m.gmane.org@sourceware.org Fri Feb 23 13:08:39 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=KkH/L1YjLxDSLkDB Vj412F78/3ujb2cAthjdmrkWGuBzJiIdI1Bjkl333OhqLVgVrNy9bteiBEOC96CR gsGvBDfFjIbsgECiG8XH4gvTkaffVgx0ny0RtygpvlW9DpeyLz+ka5Tgd6Ro8aaf 6ujJLBrq4GNxG3NOvTN9iqi5tr4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=Eu9dUQrJW3kOK7RBMMy7rl 57UiQ=; b=iGtpqKbPuZBOCqNSf9s1CxuKTMjHHNQ/Il0d5179+u8Ae7U1iYfTr3 Plzgn2euQH3bft8FvMQTsAfIBD2TqVjeqZbmPJcQFfS6bZiJ+hpcvrBQC5u6DA7A EUsLK6XVwCfB/AFeXSzOMS1J9ahKAYQYYUGFz/CjKq6qGHNpMULVU= Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-vk0-f67.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/WpdIVjx6rAhYQy7/4rbFMBPw5jMXbpWEL4v0JEhlG4=; b=Tt+OvgZVeBiBV7CVAJAJFJ9op8N1UMkSzH+Wzv9NqQSKpIxMrub1ayQgYvy8qzlWsL O6FfzI3szX0peJ09GrbbhGskBb8C/Msb6Vfo8VeppWI+uYGLMq2gox3qhKkHle47RiXD 7dR6G4pv38GAma6XEHyQRY/ar5gHj1mB9FtNoU8UhZhsHyksLQoiJrBx4bj1ydk61FKs S1+U750hbC3b7nhYcxY/CI1/C0JIE13JqxjgO4xMxfbT6HwG79vfDYw8sEwBae0jlASc nS3a0qm129IMRamWmHtOS9OKjgUIywY9aheaZrk4gihGNpcnuddoS3oaZAxjO1dcd3tJ V+5w== X-Gm-Message-State: APf1xPA5MeDd2t0m3TwUnh1MfepYTH7s0FNYWnIVzSCijeGlCC9zS7bt 7HN6KN1GzWbWOu/WKwymIQzMp5lLpzE= X-Google-Smtp-Source: AG47ELvsGGpbfh4VWy5God5nQrFPmj06g9SqUmRS2fwqCvJXZBxJcG2xHLoM6Tab1fJG9Ni5F2nF9A== X-Received: by 10.31.86.69 with SMTP id k66mr891108vkb.127.1519387836005; Fri, 23 Feb 2018 04:10:36 -0800 (PST) In-Reply-To: <6e23cc90-c734-3261-f89d-de9b83bb0a6b@redhat.com> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82861 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epC9V-0001Om-V4 for glibc-alpha@blaine.gmane.org; Fri, 23 Feb 2018 13:08:38 +0100 Received: (qmail 24381 invoked by alias); 23 Feb 2018 12:10:40 -0000 Received: (qmail 23335 invoked by uid 89); 23 Feb 2018 12:10:39 -0000 On 23/02/2018 07:41, Florian Weimer wrote: > On 02/20/2018 03:23 PM, Adhemerval Zanella wrote: > >> Aside of the two scenarios (callbacks issuing fork/pthread_atfork), the only >> other scenario I see which might trigger a deadlock in this case is a signal >> handler issuing fork/pthread_atfork. >> >> Former is BZ#4737 and my understanding is this should be a EWONTFIX due >> indication future POSIX specification to interpret fork as async-signal-unsafe >> (comment #19 and I am not sure if fork could be made async-signal-safe with >> ticket locks as Rich stated in comment #21). >> >> Regarding later I think pthread_atfork is inherent async-signal-unsafe due >> it might return ENOMEM indicating it might allocate memory and our malloc >> is also async-signal-unsafe. >> >> Am I missing a scenario you might be considering? > > I looked at the acquired locks during fork, and you are right, the corner cases where a deadlock can happen in the upstream sources are quite obscure.  However, we do not currently acquire any ld.so locks, and I think I've seen patches which change that (because upstream is buggy and crash in the new child process).  If any ld.so locks are acquired around fork, then we have a lock ordering conflict in case an ELF constructor calls pthread_register_atfork (which is an extremely natural thing to do), like this: > > Fork: > >   pthread_register_atfork lock >     rtld load lock > > dlopen: > >   rtld load lock >     calling ELF constructors, and then: >       pthread_register_atfork lock > > The older lock-free code avoids this.  You could do the same even with locks if you created a copy of the handler list on the heap. MY understanding is ld.so locks might be acquired in the callback calls from __run_fork_handlers: fork: __run_fork_handlers (atfork_run_prepare) lll_lock (atfork_lock) rtld load lock However I do not see who in a different thread dlopen would acquire the same lock since it has been already acquired by the callback. The only way is if dlopen is being called by a signal handler, which I think it another obscure corner case.