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: Tue, 20 Feb 2018 11:23:11 -0300 Message-ID: <6d6bc007-7418-4667-bf2f-0ba2256cdbec@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> 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 1519136488 30783 195.159.176.226 (20 Feb 2018 14:21:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Feb 2018 14:21:28 +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-90414-glibc-alpha=m.gmane.org@sourceware.org Tue Feb 20 15:21:24 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=I166uKaxTqwZV0lp J1l/ZnsJOB4P6kNR2B6bP4RQwn3DLHHrbx3/GZuQ43z/VaWHUguY96tQaK7LfQzY PqFeTPgeCojZn4mLUdlHgsLxud01+LywRiamM+EP9GzSXvk4+qLUrd2DK9vagUMV q4bG9ZPfx3YKwO5DUs1uTn7P1vY= 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=gjpL9+7FUlTBD6ZCWZIIm2 b9l24=; b=luNoThYeZjou9QorF2x7QvQ7A9T0sQy/mW4PtrDrIN11jPuCkgQ4yw Mfcp20wRYmXHtTH0zXuWX/Ywam1FXZEMCVwe+ILb5MhznAShvHZcqDjld46VQbVB vX2Fx3oqq4JDioeoyY5Xqn/QQnnuHRYPzNNzVSq8+gB3ItKisCJlE= 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=our, HContent-Transfer-Encoding:8bit X-HELO: mail-qt0-f193.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=8k29PkQUVkrupG9Sii3qNFDKydV+o/3LIVO2ftTnrnE=; b=KdwCeIHPTMpN0NVGrpi7KlaOHlVLqJniZhjBUyR7Dtm+q13KkLdtvr6/syMOuIJ73H PgtmNxycjsK75ToUaeiL9nMp+FKwfVBpwVDRqEDAcdOVwFqdVeKudgW+AGwKJaoMXdI0 w1GE0CoKerSNRxYlVEF3qu4jrl8FLohh25aAUduNygshIxI1rrmQ200H03RdTGZSmV83 XEu0cYmPUXp0WZ9PHu02pi1ulEUfONUb5XcPHeTWhIt7sYgQTXLi1sfCfGChL3VTXaVT qUYLtXQiLp5ErzVBARWuL9e3FDvNiGOiAvzZVYD10h4OZK3YuzMfzDujRLMiJr0H0mm2 1D7Q== X-Gm-Message-State: APf1xPA6+DH6vW7nuswrJpT72Tgx98PALmgm4o5+OiQRgHMs6MUMLqzO cHz47FI3dubjovVI3dc4UUX6opzS4dc= X-Google-Smtp-Source: AH8x226mC/MfzVH0PgPymfDo6gqp4QS49otg/WxJayb/zZ+W3q2u7rXR2WWI/jBbpuRBQcENGEx5ng== X-Received: by 10.237.36.55 with SMTP id r52mr30289246qtc.268.1519136596395; Tue, 20 Feb 2018 06:23:16 -0800 (PST) In-Reply-To: <9a266bea-818d-64da-198e-64f1c19a7915@redhat.com> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82746 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 1eo8nF-000783-ML for glibc-alpha@blaine.gmane.org; Tue, 20 Feb 2018 15:21:18 +0100 Received: (qmail 4008 invoked by alias); 20 Feb 2018 14:23:20 -0000 Received: (qmail 3998 invoked by uid 89); 20 Feb 2018 14:23:20 -0000 On 20/02/2018 10:58, Florian Weimer wrote: > On 02/20/2018 02:48 PM, Adhemerval Zanella wrote: > >> The atfork_run_prepare will instruct __run_fork_handlers to take the internal >> atfork_lock handler: >> >>    void >>    __run_fork_handlers (enum __run_fork_handler_type who) >>    { >>      struct fork_handler *runp; >> >>      if (who == atfork_run_prepare) >>        { >>          lll_lock (atfork_lock, LLL_PRIVATE); >> >> And it will prevent to add new registration until either the parent or the child >> call __run_fork_handlers with either 'atfork_run_child' or 'atfork_run_parent' >> to release the lock. > > Oh, sorry, I missed that.  So the patch does not have this problem. This does not settle the deadlock issue, though. 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?