diff options
author | Oleg Nesterov | 2011-04-01 20:11:50 +0200 |
---|---|---|
committer | Tejun Heo | 2011-04-04 02:11:04 +0200 |
commit | 1deac632fc3dcff33a6df3e82ef10c738ac13fe6 (patch) | |
tree | 137481584f4692911e2725b31776de3d2dd72068 /lib | |
parent | 244056f9dbbc6dc4126a301c745fa3dd67d8af3c (diff) |
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>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions