lkml.org 
[lkml]   [2007]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH -mm] Freezer: Handle uninterruptible tasks
On Fri, 6 Jul 2007, Rafael J. Wysocki wrote:

> Hi,
>
> The main limitation of the freezer is that it cannot handle uninterruptible
> tasks. Namely, if there are uninterruptible tasks in the system, the freezer
> returns an error, which makes it impossible to suspend the system.
>
> This mechanism is used to prevent the situations in which the suspend process
> can deadlock with a task holding a lock needed by it from happening. However,
> AFAICS, the probability of that happening is very small and if the freezer is
> removed from the suspend code patch, then the suspend process will be exposed to
> deadlocking in this manner anyway.
>
> Unfortunately, this mechanism also leads to severe limitations, such as that it
> makes the freezer unable to handle systems using FUSE in a reliable way.
>
> This patch makes the freezer skip uninterruptible user space tasks (ie. such
> that have an mm of their own) when counting the tasks to be frozen. As a
> result, these tasks have the TIF_FREEZE and TIF_SIGPENDING flags set, but the
> freezer doesn't wait for them to enter the refrigerator. Nevertheless, they
> will enter the refrigerator as soon as they change their state.

This is a very interesting idea. Are you certain it is safe? That is,
if a task is waiting for a mutex and sometime later the mutex becomes
available, will the task then enter the freezer immediately -- before
it can do any I/O or call any drivers?

If you can't make this guarantee, then you might as well simply not try
to freeze any user task until it returns from kernel mode to user mode.
And then you will face the problem of a user task doing I/O during
hibernate after the atomic snapshot has been made.


I had in mind something more complicated. My idea was to define
certain mutexes as "freezable", with the thought that it would be okay
for a task in the freezer to own freezable mutexes. None of the
mutexes needed by drivers or the PM core during a suspend transition
should be freezable.

Presumably the VFS locks _would_ fall into the freezable category. In
order for this to work, we would have to guarantee the following:

A thread blocked in the kernel waiting for some response
from userspace is allowed to hold freezable mutexes but no
other locks.

When a thread tries to acquire a freezable mutex, it is allowed
to hold other freezable mutexes but no other locks.

When the freezer is running, any task that is blocked on a
freezable mutex (maybe also any task that tries to acquire
an unlocked freezable mutex) would immediately go into the
freezer. So would any task waiting for a response from
userspace.

I think this would solve the VFS-related problems (FUSE's and others).
But obviously Raphael's approach is preferable, if it works.

Alan Stern

-
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: 2007-07-06 17:05    [W:0.309 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site