Re: Question about behavier of the freezer

["Rafael J. Wysocki" <rjw@sisk.pl>]

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