Re: 2.5.39: Signal delivery to thread groups: Bug or feature

From: Axel (Axel.Zeuner@gmx.de)
Date: Sun Sep 29 2002 - 11:56:40 EST


Hello Ingo,
On Sunday 29 September 2002 10:25, you wrote:
> On Sat, 28 Sep 2002, Axel wrote:
> > I played a little bit with the new clone flags and wrote a small test
> > program using two threads: The first (initial) thread blocks all
> > signals. The second thread is created with all signals blocked and
> > inherits the signal mask of the initial thread. It unblocks SIGINT and
> > calls sys_rt_sigtimedwait with the remaining signal mask. Therefore it
> > waits for all signals with exception of SIGINT. In the kernel this
> > yields to an empty signal mask for this thread during the sigwait. No
> > signal handler is installed by the process. Now an external SIGINT is
> > delivered to the whole process: The signal delivery code decides to send
> > this signal directly to the initial thread because no user handler is
> > installed and the signal mask for this thread blocks the signal. The
> > second thread never receives the SIGINT.
>
> could you send me the testcase? Thanks,
unfortunately, my test case is part of a thread library which was intended as
replacement for the old linuxthreads library. The idea of this library is to
have a two level thread library, i.e. posix threads with M:N scheduling on
top of posix threads with 1:1 scheduling. Starting with a 2.4.18+NGPT patches
(futexes+tkill) kernel, I implemented a user level signal forwarding scheme,
for the kernel threads, which worked as expected - slow and with a lot of
system calls.
The test program is attached - in principle a test case from NGPT (change
kth* to pthread*) and use NPT(L) as underlying library.

After having a look at your changes starting with 2.5.35? i decided to drop
further development for the old signal scheme and converted the library to
use all the advantages of the 2.5.X kernels - some of the test cases stopped
working and I had to look for the reasons.

I will test your changes to the kernel as soon as possible
IMHO, they will not work as expected, because in the function
find_unblocked_thread() the real_blocked mask of the thread is also checked:
a thread with all signals blocked calls sys_rt_sigtimedwait to wait for all
signals, all other threads block all signals. If no signal is pending, the
real_blocked mask of this thread is set to all filled and the blocked mask
of this thread is set to empty. Later a signal is sent to the process and the
find_blocked_thread function detects that the sigwait thread has this signal
not set in its blocked mask but set in its real_blocked mask and does not
deliver the signal to this thread as it should.
BTW, what is the reason for the existance of the real_blocked mask? I found a
usage of it only during the sigwaits to store the original signal mask. May
be a local variable would be a cleaner solution.

Axel

Please CC all mails to me, because I read only the archives of the
linux-kernel mailing list.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:40 EST