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

[Christian Brauner]

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 <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 ?

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