Fast sigblock (AKA rtld speedup)

[Julian Elischer]

On 1/11/13 9:31 PM, Konstantin Belousov wrote:
> On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote:
>> On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
>>> http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
>> The new fields td_sigblock_ptr and td_sigblock_val are in the part that
>> is zeroed for new threads, while the code in rtld appears to expect them
>> to be copied (on fork, vfork and pthread_create). The fields are
>> correctly zeroed on exec.
> Thank you for noting this. Should be fixed in
> http://people.freebsd.org/~kib/misc/rtld-sigblock.4.patch
>
>> Sharing the magic variable between threads means that one thread holding
>> an rtld lock will block signals for all other threads as well. This is
>> different from how the normal signal mask works but I don't know whether
>> it may break things. However, the patch depends on it in some way
>> because sigtd() does not know about fast sigblock and will therefore
>> happily select a thread that is fast-sigblocking to handle a signal
>> directed at the process.
> Hm, I do not quite follow, at least not the first part of the paragraph.
>
> The fast sigblock pointer is per-thread, so it is not shared in the kernel.
> Regardless of the kernel side, rtld is only supposed to use the fast
> block in the default implementation of the rtld locks, which are overriden
> by the libthr implementation on libthr initialization. There is also an
> explicit hand-off from the default locks to the external (libthr), and
> rtld cares to turn off fast sigblock mechanism when the handoff is
> performed.

I assume that the thread notifies the kernel of the location..

Might I suggest as a saftybelt that on notification of this address that
the kernel requires that a known "magic"  value be in this location as 
proof
that all is as expected.?  just a thought.

>
> The selection of the thread for the delivery of signal in the mt process
> should not matter then, due to the mechanism not supposed to be used
> in the mt process.
>> Although libthr's postpone approach is somewhat ugly, it does not depend
>> on any non-standard kernel features and does not delay the default
>> action. Would it be possible to move that code to libc to make things
>> easier for rtld? It looks like this requires teaching libc about various
>> threading concepts, though.
> The concern there is that rtld would need to have a tight coupling
> with libc, and possibly with libthr too.
>
>> Something feels ugly about not allowing applications to use this,
>> although I don't know how it would work. On the other hand, the strange
>> signal state created by this and implicit assumptions that the duration
>> will be short may be a reason to restrict its use to a relatively small
>> piece of code.
> Application use of the interface is equivalent to the application
> willingly corrupt its own state.