Prioritize synchronous signals over 'normal' signals
authorLinus Torvalds <torvalds@linux-foundation.org>
Tue, 2 Mar 2010 16:36:46 +0000 (08:36 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Thu, 4 Mar 2010 03:21:10 +0000 (19:21 -0800)
commita27341cd5fcb7cf2d2d4726e9f324009f7162c00
tree5b55a232509de5791ad00a15da3eaa93c3ae55c6
parenteaa5eec739637f32f8733d528ff0b94fd62b1214
Prioritize synchronous signals over 'normal' signals

This makes sure that we pick the synchronous signals caused by a
processor fault over any pending regular asynchronous signals sent to
use by [t]kill().

This is not strictly required semantics, but it makes it _much_ easier
for programs like Wine that expect to find the fault information in the
signal stack.

Without this, if a non-synchronous signal gets picked first, the delayed
asynchronous signal will have its signal context pointing to the new
signal invocation, rather than the instruction that caused the SIGSEGV
or SIGBUS in the first place.

This is not all that pretty, and we're discussing making the synchronous
signals more explicit rather than have these kinds of implicit
preferences of SIGSEGV and friends.  See for example

http://bugzilla.kernel.org/show_bug.cgi?id=15395

for some of the discussion.  But in the meantime this is a simple and
fairly straightforward work-around, and the whole

if (x & Y)
x &= Y;

thing can be compiled into (and gcc does do it) just three instructions:

movq    %rdx, %rax
andl    $Y, %eax
cmovne  %rax, %rdx

so it is at least a simple solution to a subtle issue.

Reported-and-tested-by: Pavel Vilim <wylda@volny.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kernel/signal.c