Messages in this thread Patch in this message | | | Date | Wed, 7 Apr 2004 23:30:46 +0200 | From | Pavel Machek <> | Subject | Swsusp should not wake up stopped processes |
| |
Hi!
If you stop process with ^Z, then suspend, process is awakened. Thats a bug. Solution is to simply leave already stopped processes alone. Plus we no longer use TASK_STOPPED for processes in refrigerator. Userland might see us and get confused... Please apply,
Pavel
--- clean/kernel/power/process.c 2003-08-27 12:00:53.000000000 +0200 +++ linux/kernel/power/process.c 2004-04-07 23:14:19.000000000 +0200 @@ -30,7 +30,8 @@ if ((p == current) || (p->flags & PF_IOTHREAD) || (p->state == TASK_ZOMBIE) || - (p->state == TASK_DEAD)) + (p->state == TASK_DEAD) || + (p->state == TASK_STOPPED)) return 0; return 1; } @@ -38,21 +39,19 @@ /* Refrigerator is place where frozen processes are stored :-). */ void refrigerator(unsigned long flag) { - /* You need correct to work with real-time processes. - OTOH, this way one process may see (via /proc/) some other - process in stopped state (and thereby discovered we were - suspended. We probably do not care. - */ + /* Hmm, should we be allowed to suspend when there are realtime + processes around? */ long save; save = current->state; - current->state = TASK_STOPPED; + current->state = TASK_UNINTERRUPTIBLE; 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(¤t->sighand->siglock); + recalc_sigpending(); /* We sent fake signal, clean it up */ + spin_unlock_irq(¤t->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/
| |