Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 180567 - signal mask mishandled
signal mask mishandled
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-08 19:33 EST by Ulrich Drepper
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.6.16-1.2111_FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-23 14:39:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test case from glibc to show problem. (4.99 KB, text/plain)
2006-02-08 19:33 EST, Ulrich Drepper
no flags Details
Updated patch (7.80 KB, patch)
2006-07-02 20:02 EDT, David Woodhouse
no flags Details | Diff

  None (edit)
Description Ulrich Drepper 2006-02-08 19:33:01 EST
Created attachment 124419 [details]
Test case from glibc to show problem.
Comment 1 Ulrich Drepper 2006-02-08 19:33:01 EST
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:
Comment 2 Ulrich Drepper 2006-02-09 11:57:32 EST
Actually, to compile the code use

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

(note the added -D parameter).
Comment 3 David Woodhouse 2006-02-10 07:30:14 EST
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.
Comment 4 Ulrich Drepper 2006-02-12 18:10:23 EST
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.
Comment 5 Ulrich Drepper 2006-05-27 13:44:31 EDT
Works for quite some time now.
Comment 6 David Woodhouse 2006-07-02 20:02:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.