FYI: Increase in schedlock.exp failures in LinuxThreads on an RH kernel

[Daniel Jacobowitz <drow@mvista.com>]

I noticed recently, after switching kernels (I'm temporarily running a
Debian system with a Red Hat kernel - don't ask) that schedlock.exp took a
rapid spike up in failures.  I investigated; the problem appears to be
SIGINT handling.  When the test sends a control-C, it is delivered to some
arbitrary portion of the (non-manager; this is LinuxThreads) threads.  Then,
when we next resume, the remaining threads receive it.

I think this is an old problem, just being exposed by timing.  The flush
mask in stop_wait_callback is supposed to handle this.  But since some of
the extra SIGINT signals arrive after the SIGSTOP, we can't flush them. 
This won't happen in NPTL, of course, where just one thread will get the
SIGINT.

I tried something terribly clever involving looking at the SigPnd mask in
/proc to see if a SIGINT was pending.  However, unfortunately, this kernel
(looks like... 2.4.20-18.9) introduced the shared pending queue, but did not
add ShdPnd to /proc/<pid>/status.  Therefore there's absolutely no way to
find out if a SIGINT is pending from userspace.  The SIGSTOP will always be
delivered before a pending SIGINT because we sent the SIGSTOP with tkill,
which puts it onto the more specific queue.  Any other signal we sent with
tkill would have the same problem.

In other words, on a system with this kernel and LinuxThreads, SIGINT may
stop the inferior multiple times unpredictably.  On 2.5 we'll be able to do
something about it via ShdPnd; if Red Hat fixes their kernel then we'll be
able to do something about it on RH systems, but that's not my problem.  If
the problem still manifests next time I'm in 2.5 (and I haven't switched to
NPTL :) I'll put together the fix.

Ingo/Roland - might want to export ShdPnd in the RH kernels...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer