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-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.8 required=3.0 tests=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 951531F45D for ; Mon, 23 Mar 2020 17:05:08 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D6C34385E00D; Mon, 23 Mar 2020 17:05:07 +0000 (GMT) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by sourceware.org (Postfix) with ESMTPS id 8CC5D385B832 for ; Mon, 23 Mar 2020 17:05:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CC5D385B832 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=christian.brauner@ubuntu.com Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jGQVc-0002Ls-4n; Mon, 23 Mar 2020 17:05:04 +0000 Date: Mon, 23 Mar 2020 18:05:03 +0100 From: Christian Brauner To: Mathieu Desnoyers Subject: Re: [RFC PATCH glibc 3/8] nptl: Start new threads with all signals blocked [BZ #25098] Message-ID: <20200323170503.dkaad3zmwe5owc4p@wittgenstein> References: <20200323131607.15185-1-mathieu.desnoyers@efficios.com> <20200323131607.15185-4-mathieu.desnoyers@efficios.com> <20200323153156.hpdjqghjscivggjf@wittgenstein> <1742466479.7642.1584982932053.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1742466479.7642.1584982932053.JavaMail.zimbra@efficios.com> 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: libc-alpha , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Mon, Mar 23, 2020 at 01:02:12PM -0400, Mathieu Desnoyers via Libc-alpha wrote: > ----- On Mar 23, 2020, at 11:31 AM, Christian Brauner christian.brauner@ubuntu.com wrote: > > > On Mon, Mar 23, 2020 at 09:16:02AM -0400, Mathieu Desnoyers via Libc-alpha > > wrote: > >> From: Florian Weimer > >> > >> New threads inherit the signal mask from the current thread. This > >> means that signal handlers can run on the newly created thread > >> immediately after the kernel has created the userspace thread, even > >> before glibc has initialized the TCB. Consequently, new threads can > >> observe uninitialized ctype data, among other things. > >> > >> To address this, block all signals before starting the thread, and > >> pass the original signal mask to the start routine wrapper. On the > >> new thread, first perform all thread initialization, and then unblock > >> signals. > >> > >> The cost of doing this is two rt_sigprocmask system calls on the old > >> thread, and one rt_sigprocmask system call on the new thread. (If > >> there was a way to clone a new thread with a signals disabled, this > > > > This could be a new clone3() flag. If someone wants to send a patch I'd > > take it. > > I agree that it would be a nice improvement to alleviate the overhead of > tweaking the signal masks on thread creation. I suspect the code proposed in > this patch is still needed, because glibc would have to support the currently > existing kernels. The improvement you envision involves adding this new flag > into the Linux kernel clone3 system call and then wiring up glibc support. > > I don't expect this should delay rseq integration into glibc ? Oh no, I wasn't trying to say that rseq() in glibc should be blocked on this, not at all. I was just saying we should probably do this since it's a valuable improvement. Christian