Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> The problem is in fact false negatives, where posix_spawn will get a mask 
> *without* the bit set, but with a set signal disposition.

Hmm.  Right.  Incidentally, the Go routine should be fine with that:

| // When using cgo, call the C library for sigaction, so that we call into
| // any sanitizer interceptors. This supports using the memory
| // sanitizer with Go programs. The memory sanitizer only applies to
| // C/C++ code; this permits that code to see the Go runtime's existing signal
| // handlers when registering new signal handlers for the process.
| 
| //go:cgo_import_static x_cgo_sigaction
| //go:linkname x_cgo_sigaction x_cgo_sigaction
| //go:linkname _cgo_sigaction _cgo_sigaction
| var x_cgo_sigaction byte
| var _cgo_sigaction = &x_cgo_sigaction

libjsig also keeps calling to glibc.

Is there anything else we should check?

> In fact I think due the syscall, even relaxed operations would work
> (since the syscall acts a strong memory barrier).

Only as a signal fence, not a thread fence.  Some architectures can even
keep cache inconsistency across fork system calls.

I find it a bit counter-intuitive that calling sigaction or signal
directly without the glibc wrappers could lead to data corruption, even
when done for standard signals such as SIGINT.  But that's what's going
to happen with this change, unfortunately.

>>>> I wonder if we can get kernel support for this in the new clone system
>>>> call with more flags.  Then we don't have to complicate the sigaction
>>>> implementation.
>>>
>>> Maybe a CLONE_RESET_SIGNALS where the cloned process sets its signal
>>> disposition to default SIG_IGN/SIG_DFL values may help us here.  However
>>> afaik clone now is out of space on 'flags' for newer ones (it already
>>> defines 24 flags plus it reserve 8 bits for signal to be sent at process
>>> exit) and it would take time to use this feature on glibc.
>> 
>> Christian Brauner has been working on fixing this.
>
> Which strategy he is proposing? Even with proper kernel support, it would
> take time to enable glibc to use it.

Lots of flag arguments, with the reset of the arguments located
indirectly via a pointer argument.

For a pure optimization, I think it's not too bad to require kernel
backports of system calls.

Thanks,
Florian