[PATCH 4/4] signalfd: make it group-wide, fix posix-timers scheduling

[Oleg Nesterov <oleg@tv-sign.ru>]

Untested, user visible change.

With this patch any thread can dequeue its own private signals via signalfd,
even if it was created by another sub-thread.

To do so, we pass "current" to dequeue_signal() if the caller is from the same
thread group. This also fixes the scheduling of posix timers broken by the
previous patch.

If the caller doesn't belong to this thread group, we can't handle __SI_TIMER
case properly anyway. Perhaps we should forbid the cross-process signalfd usage
and convert ctx->tsk to ctx->sighand.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

--- t/fs/signalfd.c~4_GROUP	2007-08-09 19:59:27.000000000 +0400
+++ t/fs/signalfd.c	2007-08-12 20:21:23.000000000 +0400
@@ -209,6 +209,15 @@ static int signalfd_copyinfo(struct sign
 	return err ? -EFAULT: sizeof(*uinfo);
 }
 
+static int
+__signalfd_dequeue(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
+{
+	if (tsk->tgid == current->tgid)
+		tsk = current;
+
+	return dequeue_signal(tsk, mask, info);
+}
+
 static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info,
 				int nonblock)
 {
@@ -219,7 +228,7 @@ static ssize_t signalfd_dequeue(struct s
 	if (!signalfd_lock(ctx, &lk))
 		return 0;
 
-	ret = dequeue_signal(lk.tsk, &ctx->sigmask, info);
+	ret = __signalfd_dequeue(lk.tsk, &ctx->sigmask, info);
 	switch (ret) {
 	case 0:
 		if (!nonblock)
@@ -233,7 +242,7 @@ static ssize_t signalfd_dequeue(struct s
 	add_wait_queue(&ctx->wqh, &wait);
 	for (;;) {
 		set_current_state(TASK_INTERRUPTIBLE);
-		ret = dequeue_signal(lk.tsk, &ctx->sigmask, info);
+		ret = __signalfd_dequeue(lk.tsk, &ctx->sigmask, info);
 		signalfd_unlock(&lk);
 		if (ret != 0)
 			break;
@@ -331,7 +340,7 @@ asmlinkage long sys_signalfd(int ufd, si
 
 		init_waitqueue_head(&ctx->wqh);
 		ctx->sigmask = sigmask;
-		ctx->tsk = current;
+		ctx->tsk = current->group_leader;
 
 		sighand = current->sighand;
 		/*

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/