From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 25E2A1F4B4 for ; Tue, 29 Sep 2020 14:42:12 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E3E65387087F; Tue, 29 Sep 2020 14:42:10 +0000 (GMT) Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 6AA8C3857816 for ; Tue, 29 Sep 2020 14:42:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6AA8C3857816 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Tue, 29 Sep 2020 10:42:07 -0400 From: Rich Felker To: Florian Weimer Subject: Re: [PATCH] Make abort() AS-safe (Bug 26275). Message-ID: <20200929144207.GD17637@brightrain.aerifal.cx> References: <20200927141952.121047-1-carlos@redhat.com> <871rinm1fx.fsf@mid.deneb.enyo.de> <20200928234833.GC17637@brightrain.aerifal.cx> <87d025jcn0.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d025jcn0.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Carlos O'Donell via Libc-alpha Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Tue, Sep 29, 2020 at 08:54:59AM +0200, Florian Weimer wrote: > * Rich Felker: > > > Is there a reason to take the lock across fork rather than just > > resetting it in the child? After seeing this I'm working on fixing the > > same issue in musl and was about to take the lock, but realized ours > > isn't actually protecting any userspace data state, just excluding > > sigaction on SIGABRT during abort. > > It's also necessary to stop the fork because the subprocess could > otherwise observe the impossible SIG_DFL state. In case the signal > handler returns, the implementation needs to produce a termination > status with SIGABRT as the termination signal, and the only way I can > see to achieve that is to remove the signal handler and send the > signal again. This suggests that a lock in sigaction is needed as > well. Yes, in musl we already have the lock in sigaction -- that's the whole point of the lock. To prevent other threads from fighting to change the disposition back to SIG_IGN or a signal handler while abort is trying to change it to SIG_DFL. > But for the fork case, restting the lock in the new subprocess should > be sufficient. I don't follow. Do you mean taking the lock in the parent, but just resetting it in the child? That should work but I don't see how it has any advantage over just releasing it in the child. Rich