[PATCH] zap_other_threads: don't optimize thread_group_empty() case

Nowadays thread_group_empty() and next_thread() are simple list operations,
this optimization doesn't make sense: we are doing exactly same check one
line below.

Signed-off-by: Oleg Nesterov <[email protected]>

--- t/kernel/signal.c~4_ZOT	2007-08-03 21:11:59.000000000 +0400
+++ t/kernel/signal.c	2007-08-05 19:28:13.000000000 +0400
@@ -987,9 +987,6 @@ void zap_other_threads(struct task_struc
 	p->signal->flags = SIGNAL_GROUP_EXIT;
 	p->signal->group_stop_count = 0;
 
-	if (thread_group_empty(p))
-		return;
-
 	for (t = next_thread(p); t != p; t = next_thread(t)) {
 		/*
 		 * Don't bother with already dead threads

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

---

• Follow-Ups:
  • Re: [PATCH] zap_other_threads: don't optimize thread_group_empty() case
    • From: Roland McGrath <[email protected]>

• Prev by Date: [Patch] panic.c
• Next by Date: [PATCH RT] put in a relatively high number for rcu read lock upper limit.
• Previous by thread: [Patch] panic.c
• Next by thread: Re: [PATCH] zap_other_threads: don't optimize thread_group_empty() case
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]