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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]"
