Re: [RFC PATCH glibc 3/8] nptl: Start new threads with all signals blocked [BZ #25098]

[Mathieu Desnoyers via Libc-alpha <libc-alpha@sourceware.org>]

----- 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 <fweimer@redhat.com>
>> 
>> 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