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?
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.
That said I may be missing something.
-Alfred
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
