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

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

[Daniel Jacobowitz]

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

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

[Roland McGrath]

> I noticed recently, after switching kernels (I'm temporarily running a
> Debian system with a Red Hat kernel - don't ask) 

We won't ask.  But, as you might imagine, we do run the gdb test suite on
our kernels, and we haven't seen this.  So you indeed must have hit upon a
lucky combination of hardware and software between that RH kernel and your
Debian userland that happens to bite.

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

We probably will.  I always used that patch when debugging the kernel
signals code in the past.

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

[Daniel Jacobowitz]

On Mon, Jul 28, 2003 at 12:48:17PM -0700, Roland McGrath wrote:
> > I noticed recently, after switching kernels (I'm temporarily running a
> > Debian system with a Red Hat kernel - don't ask) 
> 
> We won't ask.  But, as you might imagine, we do run the gdb test suite on
> our kernels, and we haven't seen this.  So you indeed must have hit upon a
> lucky combination of hardware and software between that RH kernel and your
> Debian userland that happens to bite.

Have you run a testsuite using LinuxThreads, but the NPTL-aware kernel? 
That should be enough to trigger it, I think.  It won't show up in
NPTL, because the SIGINT will be load balanced and only delivered to
one of the threads.

> > Ingo/Roland - might want to export ShdPnd in the RH kernels...
> 
> We probably will.  I always used that patch when debugging the kernel
> signals code in the past.

Thanks.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Roland McGrath]

> Have you run a testsuite using LinuxThreads, but the NPTL-aware kernel? 
> That should be enough to trigger it, I think.  It won't show up in
> NPTL, because the SIGINT will be load balanced and only delivered to
> one of the threads.

We certainly have in the past, and if it's not part of our regular testing
regime then we should make sure that it becomes one.  I'll have to check.

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

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Mon, Jul 28, 2003 at 12:48:17PM -0700, Roland McGrath wrote:
 > > > I noticed recently, after switching kernels (I'm temporarily running a
 > > > Debian system with a Red Hat kernel - don't ask) 
 > > 
 > > We won't ask.  But, as you might imagine, we do run the gdb test suite on
 > > our kernels, and we haven't seen this.  So you indeed must have hit upon a
 > > lucky combination of hardware and software between that RH kernel and your
 > > Debian userland that happens to bite.
 > 
 > Have you run a testsuite using LinuxThreads, but the NPTL-aware kernel? 
 > That should be enough to trigger it, I think.  It won't show up in
 > NPTL, because the SIGINT will be load balanced and only delivered to
 > one of the threads.
 > 

No, not usually. I can try though.

elena



 > > > Ingo/Roland - might want to export ShdPnd in the RH kernels...
 > > 
 > > We probably will.  I always used that patch when debugging the kernel
 > > signals code in the past.
 > 
 > Thanks.
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer