Hi! > > > > I have two questions regarding freeze_processes(): > > > > > > > > 1) Shouldn't we take the TASK_UNINTERRUPTIBLE state into consideration? Now > > > > we will fail if a process is sleeping when we try to freeze it. > > > > > > We can't allow processes to sleep at arbitrary places. Therefore we > > > send UNINTERRUPTIBLE task a signal, and hope it can get into > > > refrigerator in time. > > > > Hm, AFAIK we can't kill an UNINTERRUPTIBLE process, can we? Which means that > > we can't deliver a signal to it too ... > > Well, the problem is that signal_wake_up() is not sufficient to make > an uninterruptible task get the signal. It only sets TIF_SIGPENDING for the > task, which is not quite good, IMHO (when the task finally wakes up, > it gets the "signal" and enters refrigerator(), because it has PF_FREEZE set, > and stays there forever, as there's nothing that could clear PF_FROZEN for > it). Do you see any problem with UNINTERRUPTIBLE processess? THey should not stay in UNINTERRUPTIBLE state for too long.. If they get back into something normal within timeout, we freeze them just okay. > I think it may be fixed in one of the two ways: > > 1) We can treat uninterruptible tasks as non-freezable (in analogy to stopped > tasks) - if all of the other tasks are frozen, nothing can wake up an uninterruptible > task, so this seems to be a safe approach. HW event can wake that task up. > 2) We can try to force uninterruptible tasks to get their "signals" anyway using > wake_up_state() directly on them (which I don't like as much). They are probably uninterruptible for a reason... If something is staying in UNINTERRUPTIBLE for more than 1 second, it is going to cause problems elsewhere, anyway. Do you see that happening? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
