Hello!
The following patch fixes a locking issue in -rt signals, where the
job-control signals drop sighand_lock momentarily during signal handling.
This interacts badly with the RCU-ification of unicast signal delivery.
The fix is simply to acquire tasklist_lock for job-control signals, since
these typically do not have stringent scalability or latency requirements.
These same changes would be useful in recent -mm.
Signed-off-by: <[email protected]>
---
signal.c | 8 ++++++++
1 files changed, 8 insertions(+)
diff -urpNa -X dontdiff linux-2.6.14-rc5-rt2-ckhandRCUfix/kernel/signal.c linux-2.6.14-rc5-rt2-SIGSTOP/kernel/signal.c
--- linux-2.6.14-rc5-rt2-ckhandRCUfix/kernel/signal.c 2005-10-31 22:28:45.000000000 -0800
+++ linux-2.6.14-rc5-rt2-SIGSTOP/kernel/signal.c 2005-11-01 09:32:29.000000000 -0800
@@ -1207,13 +1207,21 @@ int
kill_proc_info(int sig, struct siginfo *info, pid_t pid)
{
int error;
+ int acquired_tasklist_lock = 0;
struct task_struct *p;
rcu_read_lock();
+ if (unlikely(sig_kernel_stop(sig) || sig == SIGCONT)) {
+ read_lock(&tasklist_lock);
+ acquired_tasklist_lock = 1;
+ }
p = find_task_by_pid(pid);
error = -ESRCH;
if (p)
error = group_send_sig_info(sig, info, p);
+ if (unlikely(acquired_tasklist_lock)) {
+ read_unlock(&tasklist_lock);
+ }
rcu_read_unlock();
return error;
}
* Paul E. McKenney <[email protected]> wrote:
> Hello!
>
> The following patch fixes a locking issue in -rt signals, where the
> job-control signals drop sighand_lock momentarily during signal
> handling. This interacts badly with the RCU-ification of unicast
> signal delivery. The fix is simply to acquire tasklist_lock for
> job-control signals, since these typically do not have stringent
> scalability or latency requirements.
thanks, applied - will show up in -rt3.
Ingo