Fast sigblock (AKA rtld speedup)

[Julian Elischer]

On 1/7/13 10:22 AM, Konstantin Belousov wrote:
> Below is the forward of the patch for which I failed to obtain a private
> review. Might be, the list generates more responses.
>
> Our rtld has a performance bootleneck, typically exposed by the images
> with the lot of the run-time relocation processing, and by the C++
> exception handling. We block the signals delivery during the rtld
> performing the relocations, as well as for the dl_iterate_phdr(3) (the
> later is used for finding the dwarf unwinding tables).
>
> The signal blocking is needed to allow the rtld to resolve the symbols
> for the signal handlers in the safe way, but also causes 2 syscalls
> overhead per each rtld entry.
>
> The proposed approach allows to shave off those two syscalls, doubling
> the FreeBSD performance for the (silly) throw/catch C++ microbenchmark.
>
> Date: Mon, 13 Aug 2012 15:26:00 +0300
> From: Konstantin Belousov <kostikbel at gmail.com>
>
> ...
>
> The basic idea is to implement sigprocmask() as single write into usermode
> address. If kernel needs to calculate the signal mask for current thread,
> it takes into the consideration non-zero value of the word at the agreed
> address. Also, usermode is informed about signals which were put on hold
> due to fast sigblock active.
>
> As I said, on my measurements in microbenchmark that did throw/catch in
> a loop, I see equal user and system time spent for unpatched system, and
> same user time with zero system time on patched system.
>
> Patch can be improved further, e.g. it would be nice to allow rtld to fall
> back to sigprocmask(2) if kernel does not support fast sigblock, to prevent
> flag day. Also, the mask enforced by fast sigblock can be made configurable.
>
> Note that libthr already blocks signals by catching them, and not using rtld
> service in the first line handler. I tried to make the change in the spirit
> of libthr interceptors, but handoff to libthr appears too complicated to
> work. In fact, libthr can be changed to start using fast sigblock instead
> of wrapping sigaction, but this is out of scope of the proposal right now.
Is there any danger that an upriveliged user program can trick the kernel
into doing anything it shouldn't by manipulating either  the agreed upon
address or the contents of the mask at the address? (even  reading
something by seeing what sigs get masked)

This was an issue with the M:N threading package and resulted in extra 
syscalls
to get around the problem. (I forget the details).