From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105706 invoked by alias); 30 Aug 2019 10:07:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 105697 invoked by uid 89); 30 Aug 2019 10:07:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=outdated X-HELO: mx1.redhat.com From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls References: <20190731183136.21545-1-adhemerval.zanella@linaro.org> <20190731183136.21545-4-adhemerval.zanella@linaro.org> <875zmg9xjr.fsf@oldenburg2.str.redhat.com> <4266b563-5433-8bb9-78a2-af0ff14cab59@linaro.org> Date: Fri, 30 Aug 2019 10:07:00 -0000 In-Reply-To: <4266b563-5433-8bb9-78a2-af0ff14cab59@linaro.org> (Adhemerval Zanella's message of "Thu, 29 Aug 2019 08:26:06 -0300") Message-ID: <87ftlj6k69.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-08/txt/msg00833.txt.bz2 * Adhemerval Zanella: > On 29/08/2019 05:38, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> * include/atomic.h (atomic_fetch_or_seq_cst, atomic_fetch_or_seq_cst): >>> New macros. >> >> Why isn't a regular release store/acquire load synchronization >> sufficient here? > > It should works, my understanding is a weaker store barrier might incur in > a slight more false positive in a highly concurrent sigaction call scenario. > But I assume that this is not a common scenario, so I used the strongest > barrier just to avoid the extra false positives. I don't see how false positives are possible. It would require bits getting set which have never been added to the mask, which would be a bug even for relaxed MO (as a QoI issue, the memory model is buggy and allows this). My main worry would be reading an outdated value in posix_spawn, but my understanding is that the release store/acquire load synchronization avoids that. >> I wonder if we can get kernel support for this in the new clone system >> call with more flags. Then we don't have to complicate the sigaction >> implementation. > > Maybe a CLONE_RESET_SIGNALS where the cloned process sets its signal > disposition to default SIG_IGN/SIG_DFL values may help us here. However > afaik clone now is out of space on 'flags' for newer ones (it already > defines 24 flags plus it reserve 8 bits for signal to be sent at process > exit) and it would take time to use this feature on glibc. Christian Brauner has been working on fixing this. Thanks, Florian