signal: prepare_signal(SIGCONT) shouldn't play with TIF_SIGPENDING
authorOleg Nesterov <oleg@redhat.com>
Fri, 1 Apr 2011 18:11:50 +0000 (20:11 +0200)
committerTejun Heo <tj@kernel.org>
Mon, 4 Apr 2011 00:11:04 +0000 (02:11 +0200)
commit1deac632fc3dcff33a6df3e82ef10c738ac13fe6
tree137481584f4692911e2725b31776de3d2dd72068
parent244056f9dbbc6dc4126a301c745fa3dd67d8af3c
signal: prepare_signal(SIGCONT) shouldn't play with TIF_SIGPENDING

prepare_signal(SIGCONT) should never set TIF_SIGPENDING or wake up
the TASK_INTERRUPTIBLE threads. We are going to call complete_signal()
which should pick the right thread correctly. All we need is to wake
up the TASK_STOPPED threads.

If the task was stopped, it can't return to usermode without taking
->siglock. Otherwise we don't care, and the spurious TIF_SIGPENDING
can't be useful.

The comment says:

* If there is a handler for SIGCONT, we must make
* sure that no thread returns to user mode before
* we post the signal

It is not clear what this means. Probably, "when there's only a single
thread" and this continues to be true. Otherwise, even if this SIGCONT
is not private, with or without this change only one thread can dequeue
SIGCONT, other threads can happily return to user mode before before
that thread handles this signal.

Note also that wake_up_state(t, __TASK_STOPPED) can't race with the task
which changes its state, TASK_STOPPED state is protected by ->siglock as
well.

In short: when it comes to signal delivery, SIGCONT is the normal signal
and does not need any special support.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
kernel/signal.c