Lines Matching full:that
17 There are three per-task flags used for that, PF_NOFREEZE, PF_FROZEN
18 and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have
28 sets this variable. After this, it executes try_to_freeze_tasks() that sends a
30 All freezable tasks must react to that by calling try_to_freeze(), which
33 it loop until PF_FROZEN is cleared for it. Then, we say that the task is
40 try_to_freeze() function (defined in include/linux/freezer.h), that checks
47 that combine interruptible sleep with checking if the task is to be frozen and
69 order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
101 IV. Why do we do that?
111 filesystem-related information that must be consistent with the state of the
115 tasks that might cause the on-disk filesystems' data and metadata to be
122 memory (approximately 50% of available RAM) and we need to do that before
125 to allocate additional memory and we prevent them from doing that by
126 freezing them earlier. [Of course, this also means that device drivers
134 safeguards against race conditions that might occur in such a case.
143 I **do** realize the IO request queue issues, and that we cannot actually do
145 avoid *that*, there's no question about that. And I suspect that stopping
152 Still, there are kernel threads that may want to be freezable. For example, if
153 a kernel thread that belongs to a device driver accesses the device directly, it
154 in principle needs to know when the device is suspended, so that it doesn't try
155 to access it at that time. However, if the kernel thread is freezable, it will
161 realizing that hibernation (or suspend) operation takes place. Ideally, user
162 space processes should not notice that such a system-wide operation has
166 for example, a process that depends on all CPUs being online while it's
168 if this process is not frozen, it may notice that the number of CPUs has
169 changed and may start to work incorrectly because of that.
178 TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B
180 may be undesirable. That's why kernel threads are not freezable by default.
186 2. Now that we have FUSE, plus the framework for doing device drivers in
188 now doing the sorts of things that kernel threads do
192 other one is more serious, but it seems that we can work around it by using
193 hibernation (and suspend) notifiers (in that case, though, we won't be able to
194 avoid the realization by the user space processes that the hibernation is taking
197 There are also problems that the freezing of tasks tends to expose, although
200 fail, because the user land process that should respond to the request is frozen
202 Suppose, however, that the firmware file is located on a filesystem accessible
203 only through another device that hasn't been resumed yet. In that case,
220 If possible, that piece of code must instead hook onto the suspend/hibernation
224 However, if that is not feasible, and grabbing 'system_transition_mutex' is deemed necessary,
226 that could lead to freezing failures, because if the suspend/hibernate code
227 successfully acquired the 'system_transition_mutex' lock, and hence that other entity failed
228 to acquire the lock, then that task would get blocked in TASK_UNINTERRUPTIBLE
229 state. As a consequence, the freezer would not be able to freeze that task,
237 mutex_[un]lock(&system_transition_mutex). That would prevent freezing failures.