linux-kernel - [RFC,PATCH 2/2] __group_complete_signal: fix? signal load-balancing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Mar 2008 01:43:21 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: [RFC,PATCH 2/2] __group_complete_signal: fix? signal load-balancing

The patch needs an ack, probably I just misunderstood the comments.

Suppose that the main thread blocks the signal. In that case
__group_complete_signal() tries to find another thread starting from
signal->curr_target.

The comment says about load-balancing, but this is not what happens?
Suppose that wants_signal(signal->curr_target) == T. In that case we
always choose the same ->curr_target thread. Isn't it better to try
to "spread" the signals over the thread group?

With this patch we are trying to find another suitable thread starting
from next_thread(signal->curr_target), thus distributing the load over
the whole thread group.

Bad idea? If not, probably we can also remove the "if (wants_signal())"
at the top of __group_complete_signal() ?

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

--- 25/kernel/signal.c~4_GCS_BALANCE	2008-03-06 01:07:55.000000000 +0300
+++ 25/kernel/signal.c	2008-03-06 01:34:57.000000000 +0300
@@ -863,13 +863,14 @@ __group_complete_signal(int sig, struct 
 		/*
 		 * Otherwise try to find a suitable thread.
 		 */
-		t = signal->curr_target;
-		if (t == NULL)
-			/* restart balancing at this thread */
-			t = signal->curr_target = p;
+		if (!signal->curr_target)
+			signal->curr_target = p;

-		while (!wants_signal(sig, t)) {
+		for (t = signal->curr_target ;; ) {
 			t = next_thread(t);
+			if (wants_signal(sig, t))
+				break;
+
 			if (t == signal->curr_target)
 				/*
 				 * No thread needs to be woken.

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