From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Cc: libc-alpha , Joseph Myers 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-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, GIT_PATCH_2, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 23 Mar 2020 17:05:06 -0000 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