Fast sigblock (AKA rtld speedup)

[Konstantin Belousov]

On Tue, Jan 08, 2013 at 01:21:48AM -0500, Alfred Perlstein wrote:
> On 1/7/13 7:08 PM, Konstantin Belousov wrote:
> > On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote:
> >> On 1/7/13 1:22 PM, 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.
> >> Very cool.
> >>
> >> Sorry for being rusty here, but is it safe to call fuword in the middle
> >> of issignal()?
> >>
> >> The reason I ask is because it looks like proc lock is required for this
> >> block, and I forget it fuword(9) can fault.
> >>
> >> If fuword(9) can fault then I don't think you can do this.
> >>
> >> You'll need to use something like fuswintr(9) or wire the page down
> >> using vslock(9) or something.
> >>
> >> I am probably missing something?
> > No, you are completely right. This is a serious bug. Thank you.
> >
> > I was careful to code the td_sigblock_val prefetch etc, but failed
> > to do the update properly. There is no reason to execute the update
> > in the issignal() at all, the setting of the pending bit can be postponed
> > to the moment after the postsig() loop was executed.
> >
> > I uploaded the updated but not yet tested patch at
> > http://people.freebsd.org/~kib/misc/rtld-sigblock.1.patch
> 
> This new patch looks like it may have issues with PSTOP.
> 
> there is a lot of code in issignal() that is missed when this code is in 
> place, I have not audited the effect of this, are you sure this is what 
> will work for the majority of cases?
What exactly you are concerned with ? Note that fastblock_mask manipulations
right before setting of TDP_FAST_SIGPENDING is to disallow the postponing
of the delivery of (potentially) synchronous signals caused by traps, as
well as SIGKILL/SIGSTOP.

> 
> Honestly, if I were coding it for correctness I would vslock the pages 
> (or otherwise wire them in) and let issignal() behave normally and not 
> early exit from it.
vslock() is racy, causes user address space fragmentation and was simply
impossibly to use correctly until very recent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130108/b0e2a7f2/attachment.sig>