Re: Re: freeze_processes questions

Alan Stern
2005-04-07T14:36:24Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1581 bytes --]

On Thu, 7 Apr 2005, Rafael J. Wysocki wrote:

> I am confused now. AFAICS, we don't check anywhere if a process we
> are going to freeze holds any locks.

You're not supposed to check. If the process is running in userspace then
it can't be holding any locks, by definition. If it's running in the
kernel then it's supposed to do its own checking. It won't call
refrigerator() unless it knows that no locks are held.

> If we have a task in
> TASK_INTERRUPTIBLE, we just send it a fake signal which causes it to go
> to the refrigerator(). Could you please tell me how we prevent such a task
> from holding any locks? [It probably doesn't matter, at least practically,
> but ...? :-)]

You can't prevent it, and what you're doing is a mistake.

> > OTOH... we may want to move completely away from refrigerator. Its
> > quite a hack, and it device support is okay, we'll not really need it.
>
> Still, it won't happen soon, I guess. :-) As of today, we have the
> refrigerator and the processes in TASK_UNINTERRUPTIBLE are mishandled.
> I think we should do something about it, at least for now, until we drop
> the refrigerator altogether (if we are going to drop it). That's why I
> started the discussion and sent the patch.

It's very simple. Processes in TASK_UNINTERRUPTIBLE can't be put in the
refrigerator, so you have to wait until they can be put there. If that
means waiting more than 10 seconds or so, you should just give up.
Return an error and put a message in the log saying something like "Can't
suspend because process XXX is busy".

Alan Stern