On Thu, 7 Apr 2005, Rafael J. Wysocki wrote: > > 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. > > It seems that if a process calls wait_for_completion() right before suspend, > the other task supposed to complete its completion may be accidentally frozen > before it's able to do this. It looks like this happens to kseroid sometimes > on suspend-during-resume. You mean, when a suspend occurs so soon after a resume that the resume has fully completed yet? Aren't there interlocks to prevent that sort of thing from happening? Anyway, if a process is waiting for something that's not going to happen because some other process is frozen, then the suspend should fail. I don't see any other choice. However, it might help in some situations to send a FREEZE message to some device drivers before putting processes in the refrigerator -- especially drivers that use a kernel thread. > > 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". > > OK, that's what we do now. Except that IMO we should clear the PF_FREEZE flag > for this process and do recalc_sigpending() for it after we give up, because > otherwise it will enter the refrigerator sooner or later and it will stay there. > Alternatively, we can disable the "freezing loop" in refrigerator() as soon as > thaw_processes() is started. Also, we can avoid setting PF_FREEZE for > processes in TASK_UNINTERRUPTIBLE, but count them as "freezable". Etc. Yes, all the necessary cleanup steps should be taken. Alan Stern
