Re: Re: [PATCH] Remove process freezer from suspend to RAM pathway

Alan Stern
2007-07-05T14:23:48Z

On Thu, 5 Jul 2007, Paul Mackerras wrote:

> Alan Stern writes:
>
> > Let's agree the kernel threads and the freezer are a separate issue.
>
> No, I don't think they are a separate issue, because I think the
> distinction the freezer makes between kernel threads and user threads
> is a false and misleading distinction.

That's a little strong. "Misleading" I could understand, but "false"?
Isn't the distinction between a kernel thread and a user task pretty
clear-cut (except for a few borderline cases which aren't at issue just
now)?

> > I agree the kernel threads which try to do I/O during a suspend will
> > need extra attention. However if these threads are necessary for the
> > suspend procedure, then blocking them (which is how people on this
> > thread have been saying driver should treat I/O requests during a
> > suspend) will cause additional problems. There's no way around it;
> > these threads _will_ require more work.
>
> There is a way around it; do the request blocking in the drivers,
> where it belongs.

How will that help? Block the kernel thread in the freezer or block it
in the driver -- either way it is blocked. So how do your deadlocks
get resolved?

> In general the only way to guarantee there are no deadlocks is to
> construct the graph of dependencies between tasks. Those dependencies
> are not in practice observable from outside the tasks, so it is
> virtually impossible to construct the graph.
>
> The "don't freeze kernel threads" thing is an attempt to make a crude
> approximation to the dependency graph (by saying kernel threads only
> depend on other kernel threads), but the approximation breaks down
> when you have FUSE or user-level device drivers.

I disagree with your analysis -- not that it's completely wrong, but it
points out an existing basic problem in the kernel. The kernel should
never depend on userspace! More correctly, a task executing in the
kernel should never block with any sort of mutex or other lock held (in
a way that would preclude it from being frozen, let's say) while
waiting for a response from userspace.

Then the dependency graph would be easy to construct: User tasks can
depend on whatever they want, and kernel threads never depend on a user
task.

If this contradicts the existing implementations and APIs for userspace
filesystems, then so be it. My conclusion would be that the
implementations and APIs should be changed.

> > There remains the problem of user tasks whose assistance is required to
> > carry out some I/O (as with FUSE). If the I/O can be deferred until
> > after the resume, then there's no problem. If the I/O can be carried
> > out before the suspend, then it should be. And finally, if the I/O
> > must be done during the suspend, you're in real trouble -- how do you
> > do I/O to a suspended device?
>
> So why doesn't that argument apply to kernel threads? :)

It _does_ apply to kernel threads. That's exactly why I wrote above
that kernel threads which try to do I/O during a suspend will need
extra attention.

Alan Stern