aboutsummaryrefslogtreecommitdiff
path: root/crypto/xts.c
diff options
context:
space:
mode:
authorOleg Nesterov2011-04-01 20:11:50 +0200
committerTejun Heo2011-04-04 02:11:04 +0200
commit1deac632fc3dcff33a6df3e82ef10c738ac13fe6 (patch)
tree137481584f4692911e2725b31776de3d2dd72068 /crypto/xts.c
parent244056f9dbbc6dc4126a301c745fa3dd67d8af3c (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 'crypto/xts.c')
0 files changed, 0 insertions, 0 deletions