On Mon, Jan 07, 2013 at 12:18:41PM -0800, Julian Elischer wrote: > 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 <kostik...@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) I do not see how would anything like this possible.
> > This was an issue with the M:N threading package and resulted in extra > syscalls > to get around the problem. (I forget the details). Would be great to dig up the details indeed. I cannot comment otherwise.
pgpY8Fi8Hqf9Z.pgp
Description: PGP signature
