lkml.org 
[lkml]   [2003]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[pm] Better method of getting rid of signals
Hi!

recalc_sigpending() seems like better idea, since it does not have
potential to kill some signal. Now with proper locking. Please apply,

Pavel

--- tmp/linux/kernel/power/process.c 2003-08-27 12:00:53.000000000 +0200
+++ linux/kernel/power/process.c 2003-10-09 11:21:14.000000000 +0200
@@ -49,10 +49,11 @@
pr_debug("%s entered refrigerator\n", current->comm);
printk("=");
current->flags &= ~PF_FREEZE;
- if (flag)
- flush_signals(current); /* We have signaled a kernel thread, which isn't normal behaviour
- and that may lead to 100%CPU sucking because those threads
- just don't manage signals. */
+
+ spin_lock_irq(&current->sighand->siglock);
+ recalc_sigpending(); /* We sent fake signal, clean it up */
+ spin_unlock_irq(&current->sighand->siglock);
+
current->flags |= PF_FROZEN;
while (current->flags & PF_FROZEN)
schedule();
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.037 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site