Lines Matching refs:that

12 There are three per-task flags used for that, PF_NOFREEZE, PF_FROZEN
13 and PF_FREEZER_SKIP (the last one is auxiliary).  The tasks that have
23 sets this variable.  After this, it executes try_to_freeze_tasks() that sends a
25 All freezable tasks must react to that by calling try_to_freeze(), which
28 it loop until PF_FROZEN is cleared for it. Then, we say that the task is
35 try_to_freeze() function (defined in include/linux/freezer.h), that checks
42 that combine interruptible sleep with checking if the task is to be frozen and
64 order to clear the PF_FROZEN flag for each frozen task.  Then, the tasks that
95 IV. Why do we do that?
104 filesystem-related information that must be consistent with the state of the
107 making them almost impossible to repair).  We therefore freeze tasks that might
114 memory (approximately 50% of available RAM) and we need to do that before
117 additional memory and we prevent them from doing that by freezing them earlier.
118 [Of course, this also means that device drivers should not allocate substantial
126 safeguards against race conditions that might occur in such a case.
135 I _do_ realize the IO request queue issues, and that we cannot actually do
137 avoid *that*, there's no question about that.  And I suspect that stopping
144 Still, there are kernel threads that may want to be freezable.  For example, if
145 a kernel thread that belongs to a device driver accesses the device directly, it
146 in principle needs to know when the device is suspended, so that it doesn't try
147 to access it at that time.  However, if the kernel thread is freezable, it will
153 realizing that hibernation (or suspend) operation takes place.  Ideally, user
154 space processes should not notice that such a system-wide operation has occurred
158 that depends on all CPUs being online while it's running.  Since we need to
160 may notice that the number of CPUs has changed and may start to work incorrectly
161 because of that.
169 TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B
176 2. Now that we have FUSE, plus the framework for doing device drivers in
178 now doing the sorts of things that kernel threads do
182 other one is more serious, but it seems that we can work around it by using
183 hibernation (and suspend) notifiers (in that case, though, we won't be able to
184 avoid the realization by the user space processes that the hibernation is taking
187 There are also problems that the freezing of tasks tends to expose, although
190 fail, because the user land process that should respond to the request is frozen
192 Suppose, however, that the firmware file is located on a filesystem accessible
193 only through another device that hasn't been resumed yet.  In that case,
208 If possible, that piece of code must instead hook onto the suspend/hibernation
212 However, if that is not feasible, and grabbing 'pm_mutex' is deemed necessary,
214 that could lead to freezing failures, because if the suspend/hibernate code
215 successfully acquired the 'pm_mutex' lock, and hence that other entity failed
216 to acquire the lock, then that task would get blocked in TASK_UNINTERRUPTIBLE
217 state. As a consequence, the freezer would not be able to freeze that task,