Question about behavier of the freezer

Question about behavier of the freezer

[Maxim Levitsky]

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)

Kernel thread can became freezable, and then it is frozen when it calls
try_to_freeze.

I also know that userspace program that is in TASK_UNINTERRUPTIBLE can't
be frozen, and breaks suspend.

Now what happens if userspace thread is TASK_RUNNING? Can it be
interrupted inside the kernel?

Or in other words, userspace thread can be interrupted to receive signal
while inside the kernel?

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.

Did I answer my own question?

Best regards,
Maxim Levitsky

Re: Question about behavier of the freezer

[Rafael J. Wysocki]

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