On Sunday 24 January 2010, Maxim Levitsky wrote: > I know following things: > > All kernel threads aren't freezable by default, thus are running while > suspend/resume is done. (Of course this is unless thread sleeps on a > lock, or when pm core enters atomic context) There are some freezable kernel threads. Please grep the kernel sources for set_freezable to find them. > Kernel thread can became freezable, and then it is frozen when it calls > try_to_freeze. They become freezable when they cally set_freezable() and then they have to call try_to_freeze() periodically to poll for freezing requests. > I also know that userspace program that is in TASK_UNINTERRUPTIBLE can't > be frozen, and breaks suspend. That's correct. > Now what happens if userspace thread is TASK_RUNNING? Can it be > interrupted inside the kernel? It gets a fake signal and will be frozen while returning to the user space. > Or in other words, userspace thread can be interrupted to receive signal > while inside the kernel? No, but it has to return to the user space at one point. > I think that signals are only delivered if userspace task in running in > user mode. If it is in TASK_INTERRUPTIBLE, then the task will be woken > up (this is corresponding wait function will return some predefined > error message, and then kernel code will try to return to userspace as > fast as possible. When task returns to userspace, right away the signal > handler is called. Yes, signals are generally checked for on return from the kernel space to the user space, IIRC. > Did I answer my own question? I think so. :-) Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
