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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 3AA941F45D for ; Mon, 23 Mar 2020 17:02:17 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E13E7385C426; Mon, 23 Mar 2020 17:02:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E13E7385C426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1584982935; bh=MQmAM/L8D2mIQzXuW35BGZnOt9ouoxEvTd1ZfJoGuhY=; h=Date:To:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=xPlkBu+o5LNIRBverlSiDURzvfLKf4Id5lY+9rn5RKBK1mHngY7Qf2vptz9dLvZ4P iKgjOok8ffVE/uoUN5bCGG1l4TiUfeMmbrtkM9DZp7vVvBFOCxcOIkPdJMHBxMJCR+ rg7tryJk/af2Sn5N5G8qEM24cmcH8mUiOhcrSnlk= Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id D0757385B832 for ; Mon, 23 Mar 2020 17:02:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D0757385B832 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 8299F24993F; Mon, 23 Mar 2020 13:02:12 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ad0ByAHmw5mi; Mon, 23 Mar 2020 13:02:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 3A76524993E; Mon, 23 Mar 2020 13:02:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 3A76524993E X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b8tdz0dV2_or; Mon, 23 Mar 2020 13:02:12 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 2CBC1249B84; Mon, 23 Mar 2020 13:02:12 -0400 (EDT) Date: Mon, 23 Mar 2020 13:02:12 -0400 (EDT) To: Christian Brauner Message-ID: <1742466479.7642.1584982932053.JavaMail.zimbra@efficios.com> In-Reply-To: <20200323153156.hpdjqghjscivggjf@wittgenstein> References: <20200323131607.15185-1-mathieu.desnoyers@efficios.com> <20200323131607.15185-4-mathieu.desnoyers@efficios.com> <20200323153156.hpdjqghjscivggjf@wittgenstein> Subject: Re: [RFC PATCH glibc 3/8] nptl: Start new threads with all signals blocked [BZ #25098] MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3918 (ZimbraWebClient - FF74 (Linux)/8.8.15_GA_3895) Thread-Topic: nptl: Start new threads with all signals blocked [BZ #25098] Thread-Index: 9MDuETuGguBfUazTTUukF2zY5Oho3Q== 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: , From: Mathieu Desnoyers via Libc-alpha Reply-To: Mathieu Desnoyers Cc: libc-alpha , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" ----- 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 ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com