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.4 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 66A551F66F for ; Thu, 19 Nov 2020 15:40:03 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 13B4B387090A; Thu, 19 Nov 2020 15:40:02 +0000 (GMT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by sourceware.org (Postfix) with ESMTPS id 114A63851C39 for ; Thu, 19 Nov 2020 15:40:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 114A63851C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=panix.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zackw@panix.com Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4CcP4v5JSTz1VPd for ; Thu, 19 Nov 2020 10:39:59 -0500 (EST) Received: by mail-ed1-f46.google.com with SMTP id m16so6308927edr.3 for ; Thu, 19 Nov 2020 07:39:59 -0800 (PST) X-Gm-Message-State: AOAM533K7+qSTDWNQTRs+trDEmWf+QIuCDetprFvX8MUZuBNSPJB/2Ia AAF4YyCPS8i08Pk7tPk1FLLEx6u6PdCmPH++xIg= X-Google-Smtp-Source: ABdhPJxdin9BSoVO4HUpX6zSJORmrBsdUbj2uwkq1aOGeDgFEIi0KYmffN0OfGn1SmrAoKGGJgUq559HU52wcEiGLP0= X-Received: by 2002:aa7:c904:: with SMTP id b4mr5956198edt.161.1605800398779; Thu, 19 Nov 2020 07:39:58 -0800 (PST) MIME-Version: 1.0 References: <87lfeyvghf.fsf@mid.deneb.enyo.de> <20201118170434.GF6882@arm.com> <873616va9n.fsf@mid.deneb.enyo.de> <20201118180927.GI6882@arm.com> <20201119145934.GC20578@arm.com> In-Reply-To: <20201119145934.GC20578@arm.com> From: Zack Weinberg Date: Thu, 19 Nov 2020 10:39:47 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: PING: V7 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] To: Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" 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: Florian Weimer , "H.J. Lu via Libc-alpha" , Dave Martin , Joseph Myers , Rich Felker Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Thu, Nov 19, 2020 at 10:00 AM Szabolcs Nagy via Libc-alpha wrote: ... > but to let the critical section with all its side > effects complete and delay the signal handler > until then. (the slow and easy way to do this is > masking signals using syscalls around critical > sections, a fast solution needs signal wrapping > and saving the sigcontext.) > > for example the entire malloc call can be a critical > section and an incomming signal delayed until malloc > completes. I read this and I'm wondering how impractical it would be to invent a way to perform pthread_sigmask() operations without a system call. Abstractly, the signal mask for each thread _could_ be placed in user space at an ABI-specified location where the kernel can find it (bottom of the thread stack, maybe, or an offset from the TLS base); this doesn't make anything new possible (the kernel will just continue to ignore the bits for SIGKILL, SIGSEGV, etc.) so it wouldn't be a privilege violation. Seems like that would be much easier than copying sigcontexts around, and less likely to break code that thinks it knows stuff about signal frames. zw