From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67229 invoked by alias); 14 Oct 2019 13:32:36 -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 67217 invoked by uid 89); 14 Oct 2019 13:32:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:949 X-HELO: youngberry.canonical.com Date: Mon, 14 Oct 2019 13:32:00 -0000 From: Christian Brauner To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] nptl: Start new threads with all signals blocked [BZ #25098] Message-ID: <20191014133231.sa4zalwbsiybpyvj@wittgenstein> References: <87k197ik0o.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87k197ik0o.fsf@oldenburg2.str.redhat.com> User-Agent: NeoMutt/20180716 X-SW-Source: 2019-10/txt/msg00385.txt.bz2 On Mon, Oct 14, 2019 at 02:33:43PM +0200, Florian Weimer wrote: > 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 He, do I see a growing wishlist? :) Christian