From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Florian Weimer Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 3/3] Refactor atfork handlers Date: Tue, 27 Feb 2018 09:25:23 +0100 Message-ID: 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> <84558035-c0a9-c83f-382c-ec7f87955a21@linaro.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519719811 25236 195.159.176.226 (27 Feb 2018 08:23:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Feb 2018 08:23:31 +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: Adhemerval Zanella Original-X-From: libc-alpha-return-90652-glibc-alpha=m.gmane.org@sourceware.org Tue Feb 27 09:23:27 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=cW5+ODLrps9TJWS5 wsTmr8P5Ip14MRuzZnk8bGfsxh0ZL/Fw+i3m9x+BkHTBgH29NRxYGwbhFWuiMeG4 aTDs0pUeFdzQxbbgRrgwT31n7xxtmK7JtPXHK9lsflscB0Kel9x+P8kAuyv6eXwf FaszcedeRk/fFNnq83jPtT1u91A= 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=Z0DW22+7VTkkLIx1xCUVjo 89iME=; b=ZZ9iguZe7OAz4ECjAsmv70avaj39LZMYQc2zQkwI9rlsZCF7+CbUDY jDdFAz9eg8xY/s0dDhNZSVhDrxzjK7m6qatPbLt6lylInjdq2AymcfpwAwWJnWQn txXuscXKEmUt4ANql51A506FmhppTWhJMAUtC/GrJwaIy81gTN3RM= 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=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com In-Reply-To: <84558035-c0a9-c83f-382c-ec7f87955a21@linaro.org> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82983 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 1eqaXk-000617-Mt for glibc-alpha@blaine.gmane.org; Tue, 27 Feb 2018 09:23:25 +0100 Received: (qmail 74059 invoked by alias); 27 Feb 2018 08:25:27 -0000 Received: (qmail 74047 invoked by uid 89); 27 Feb 2018 08:25:26 -0000 On 02/23/2018 01:10 PM, Adhemerval Zanella wrote: > 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 Yes, that could happen even with the existing code. My concern was with certain downstream patches in some distributions which acquire the rtld lock around fork, to avoid potentially corrupting the dynamic linker state in the child process (because the fork can no longer race with rtld data structure updates). > 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. I meant that one thread would acquire the rtld lock first, and another thread would attempt to acquire the atfork lock, and then they proceed to acquire the opposite lock, which will deadlock. Thanks, Florian