Description of problem:
The signal mask seem to be mishandled or ignored on current x86-64 kernels.  I
tried 1.1909 and 1.1913, Jeremy tried 1.1884.

The symptoms are that signals get delivered to threads which have the signal
blocked.  I attach a test program.  The program creates a number of threads,
blocks all signals in the first created thread, allows one signal in the second,
two in the third threads, etc.  Then it sends a total of 10,000 signals.  The
expectation is, of course, that the no signal is sent to a thread which has it
blocked.

Version-Release number of selected component (if applicable):
2.6.15-1.1913_FC5

How reproducible:
always

Steps to Reproduce:
1.compile attached program with gcc -o tst-signal3 tst-signal3.c -O2 -lpthread
2.run
3.
  
Actual results:
The output currently looks like this:

thread 0 received signal SIGRTMIN+1
thread 0 received signal SIGRTMIN+2
thread 0 received signal SIGRTMIN+3
thread 0 received signal SIGRTMIN+4
thread 0 received signal SIGRTMIN+5
thread 0 received signal SIGRTMIN+6
thread 0 received signal SIGRTMIN+7
thread 0 received signal SIGRTMIN+8
thread 0 received signal SIGRTMIN+9
thread 1 received signal SIGRTMIN+2
thread 1 received signal SIGRTMIN+3
thread 1 received signal SIGRTMIN+4
thread 1 received signal SIGRTMIN+5
thread 1 received signal SIGRTMIN+6
thread 1 received signal SIGRTMIN+7
thread 1 received signal SIGRTMIN+8
thread 1 received signal SIGRTMIN+9
thread 2 received signal SIGRTMIN+3
thread 2 received signal SIGRTMIN+4
thread 2 received signal SIGRTMIN+5
thread 2 received signal SIGRTMIN+6
thread 2 received signal SIGRTMIN+7
thread 2 received signal SIGRTMIN+8
thread 2 received signal SIGRTMIN+9
thread 3 received signal SIGRTMIN+4
thread 3 received signal SIGRTMIN+5
thread 3 received signal SIGRTMIN+6
thread 3 received signal SIGRTMIN+7
thread 3 received signal SIGRTMIN+8
thread 3 received signal SIGRTMIN+9
thread 4 received signal SIGRTMIN+5
thread 4 received signal SIGRTMIN+6
thread 4 received signal SIGRTMIN+7
thread 4 received signal SIGRTMIN+8
thread 4 received signal SIGRTMIN+9
thread 5 received signal SIGRTMIN+6
thread 5 received signal SIGRTMIN+7
thread 5 received signal SIGRTMIN+8
thread 5 received signal SIGRTMIN+9
thread 6 received signal SIGRTMIN+7
thread 6 received signal SIGRTMIN+8
thread 6 received signal SIGRTMIN+9
thread 7 received signal SIGRTMIN+8
thread 7 received signal SIGRTMIN+9
thread 8 received signal SIGRTMIN+9
total number of handled signals is 5632, expected 10000
A total of 5632 signals sent and received
thread  0:    84
thread  1:    41    31
thread  2:    90   108    98
thread  3:   206   198   213   201
thread  4:   121    95    97   117    73
thread  5:    77    93    84    86    81    93
thread  6:    94   108    91    89    83   100    85
thread  7:    86    71    91    82    77   101   101   114
thread  8:   102    93    76   108   111    86   102    90    99
thread  9:   118   101   102   107   127   104   106   115   111   114

Total    :  1019   898   852   790   552   484   394   319   210   114

All the lines before 'total number of handled...' are error messages.  These
indicate misdirected signals.  I.e., thread 0 should have received any signal etc.


Expected results:
The output should look like this:

A total of 10000 signals sent and received
thread  0:    80
thread  1:    22    75
thread  2:    29    35    78
thread  3:    41    42    40   122
thread  4:    42    54    47    66   136
thread  5:    78    73    91    87   100   192
thread  6:   122   118   123   120   108   153   286
thread  7:   171   160   146   205   201   194   197   409
thread  8:   206   207   211   204   216   236   266   324   592
thread  9:   228   214   237   224   221   205   244   296   387  1039

Total    :  1019   978   973  1028   982   980   993  1029   979  1039

The actual numbers look different because the thread which gets selected to
receive the signal is semi-random.  But the numbers add up to 10,000 as the
first like says.


Additional info:

Actually, to compile the code use

gcc -o tst-signal3 tst-signal3.c -O2 -lpthread -D_GNU_SOURCE

(note the added -D parameter).

This is probably caused by the TIF_RESTORE_SIGMASK/sigsuspend patches for
x86_64. Which is odd, because they're based closely on the equivalent for i386
which works fine. Investigating further.... see also bug #179228.

The 1936 does not have this problem.  If this was achieved by reverting a patch
I suggest this bug remains open until the real solution is checked in and tested.

Works for quite some time now.

Created attachment 131868 [details]
Updated patch

Updated version of the original patch which got reverted.

This adds the TIF_RESTORE_SIGMASK functionality required for pselect and ppoll
system calls, and shouldn't suffer from the same problem as the original.