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
