^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Freezing of tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) I. What is the freezing of tasks?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) The freezing of tasks is a mechanism by which user space processes and some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) kernel threads are controlled during hibernation or system-wide suspend (on some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) architectures).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) II. How does it work?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) There are three per-task flags used for that, PF_NOFREEZE, PF_FROZEN
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) PF_NOFREEZE unset (all user space processes and some kernel threads) are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) regarded as 'freezable' and treated in a special way before the system enters a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) suspend state as well as before a hibernation image is created (in what follows
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) we only consider hibernation, but the description also applies to suspend).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Namely, as the first step of the hibernation procedure the function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) freeze_processes() (defined in kernel/power/process.c) is called. A system-wide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) variable system_freezing_cnt (as opposed to a per-task flag) is used to indicate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) whether the system is to undergo a freezing operation. And freeze_processes()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) sets this variable. After this, it executes try_to_freeze_tasks() that sends a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) fake signal to all user space processes, and wakes up all the kernel threads.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) All freezable tasks must react to that by calling try_to_freeze(), which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) results in a call to __refrigerator() (defined in kernel/freezer.c), which sets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) the task's PF_FROZEN flag, changes its state to TASK_UNINTERRUPTIBLE and makes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) it loop until PF_FROZEN is cleared for it. Then, we say that the task is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 'frozen' and therefore the set of functions handling this mechanism is referred
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) to as 'the freezer' (these functions are defined in kernel/power/process.c,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) kernel/freezer.c & include/linux/freezer.h). User space processes are generally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) frozen before kernel threads.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) __refrigerator() must not be called directly. Instead, use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) try_to_freeze() function (defined in include/linux/freezer.h), that checks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) if the task is to be frozen and makes the task enter __refrigerator().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) For user space processes try_to_freeze() is called automatically from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) signal-handling code, but the freezable kernel threads need to call it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) explicitly in suitable places or use the wait_event_freezable() or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) wait_event_freezable_timeout() macros (defined in include/linux/freezer.h)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) that combine interruptible sleep with checking if the task is to be frozen and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) calling try_to_freeze(). The main loop of a freezable kernel thread may look
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) like the following one::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) set_freezable();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) do {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) hub_events();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) wait_event_freezable(khubd_wait,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) !list_empty(&hub_event_list) ||
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) kthread_should_stop());
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) } while (!kthread_should_stop() || !list_empty(&hub_event_list));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) (from drivers/usb/core/hub.c::hub_thread()).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) If a freezable kernel thread fails to call try_to_freeze() after the freezer has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) initiated a freezing operation, the freezing of tasks will fail and the entire
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) hibernation operation will be cancelled. For this reason, freezable kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) threads must call try_to_freeze() somewhere or use one of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) wait_event_freezable() and wait_event_freezable_timeout() macros.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) After the system memory state has been restored from a hibernation image and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) devices have been reinitialized, the function thaw_processes() is called in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) have been frozen leave __refrigerator() and continue running.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) Rationale behind the functions dealing with freezing and thawing of tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) -------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) freeze_processes():
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) - freezes only userspace tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) freeze_kernel_threads():
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) - freezes all tasks (including kernel threads) because we can't freeze
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) kernel threads without freezing userspace tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) thaw_kernel_threads():
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) - thaws only kernel threads; this is particularly useful if we need to do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) anything special in between thawing of kernel threads and thawing of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) userspace tasks, or if we want to postpone the thawing of userspace tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) thaw_processes():
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) - thaws all tasks (including kernel threads) because we can't thaw userspace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) tasks without thawing kernel threads
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) III. Which kernel threads are freezable?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) ========================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) Kernel threads are not freezable by default. However, a kernel thread may clear
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) directly is not allowed). From this point it is regarded as freezable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) and must call try_to_freeze() in a suitable place.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) IV. Why do we do that?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) Generally speaking, there is a couple of reasons to use the freezing of tasks:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) 1. The principal reason is to prevent filesystems from being damaged after
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) hibernation. At the moment we have no simple means of checkpointing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) filesystems, so if there are any modifications made to filesystem data and/or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) metadata on disks, we cannot bring them back to the state from before the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) modifications. At the same time each hibernation image contains some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) filesystem-related information that must be consistent with the state of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) on-disk data and metadata after the system memory state has been restored
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) from the image (otherwise the filesystems will be damaged in a nasty way,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) usually making them almost impossible to repair). We therefore freeze
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) tasks that might cause the on-disk filesystems' data and metadata to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) modified after the hibernation image has been created and before the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) system is finally powered off. The majority of these are user space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) processes, but if any of the kernel threads may cause something like this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) to happen, they have to be freezable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 2. Next, to create the hibernation image we need to free a sufficient amount of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) memory (approximately 50% of available RAM) and we need to do that before
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) devices are deactivated, because we generally need them for swapping out.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) Then, after the memory for the image has been freed, we don't want tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) to allocate additional memory and we prevent them from doing that by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) freezing them earlier. [Of course, this also means that device drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) should not allocate substantial amounts of memory from their .suspend()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) callbacks before hibernation, but this is a separate issue.]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) 3. The third reason is to prevent user space processes and some kernel threads
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) from interfering with the suspending and resuming of devices. A user space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) process running on a second CPU while we are suspending devices may, for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) example, be troublesome and without the freezing of tasks we would need some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) safeguards against race conditions that might occur in such a case.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) Although Linus Torvalds doesn't like the freezing of tasks, he said this in one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) "RJW:> Why we freeze tasks at all or why we freeze kernel threads?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) Linus: In many ways, 'at all'.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) I **do** realize the IO request queue issues, and that we cannot actually do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) s2ram with some devices in the middle of a DMA. So we want to be able to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) avoid *that*, there's no question about that. And I suspect that stopping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) user threads and then waiting for a sync is practically one of the easier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) ways to do so.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) So in practice, the 'at all' may become a 'why freeze kernel threads?' and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) freezing user threads I don't find really objectionable."
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) Still, there are kernel threads that may want to be freezable. For example, if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) a kernel thread that belongs to a device driver accesses the device directly, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) in principle needs to know when the device is suspended, so that it doesn't try
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) to access it at that time. However, if the kernel thread is freezable, it will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) be frozen before the driver's .suspend() callback is executed and it will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) thawed after the driver's .resume() callback has run, so it won't be accessing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) the device while it's suspended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) 4. Another reason for freezing tasks is to prevent user space processes from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) realizing that hibernation (or suspend) operation takes place. Ideally, user
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) space processes should not notice that such a system-wide operation has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) occurred and should continue running without any problems after the restore
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) (or resume from suspend). Unfortunately, in the most general case this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) is quite difficult to achieve without the freezing of tasks. Consider,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) for example, a process that depends on all CPUs being online while it's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) running. Since we need to disable nonboot CPUs during the hibernation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) if this process is not frozen, it may notice that the number of CPUs has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) changed and may start to work incorrectly because of that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) V. Are there any problems related to the freezing of tasks?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) ===========================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) Yes, there are.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) First of all, the freezing of kernel threads may be tricky if they depend one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) on another. For example, if kernel thread A waits for a completion (in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) TASK_UNINTERRUPTIBLE state) that needs to be done by freezable kernel thread B
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) and B is frozen in the meantime, then A will be blocked until B is thawed, which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) may be undesirable. That's why kernel threads are not freezable by default.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) Second, there are the following two problems related to the freezing of user
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) space processes:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) 1. Putting processes into an uninterruptible sleep distorts the load average.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) 2. Now that we have FUSE, plus the framework for doing device drivers in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) userspace, it gets even more complicated because some userspace processes are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) now doing the sorts of things that kernel threads do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) (https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012309.html).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) The problem 1. seems to be fixable, although it hasn't been fixed so far. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) other one is more serious, but it seems that we can work around it by using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) hibernation (and suspend) notifiers (in that case, though, we won't be able to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) avoid the realization by the user space processes that the hibernation is taking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) place).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) There are also problems that the freezing of tasks tends to expose, although
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) they are not directly related to it. For example, if request_firmware() is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) called from a device driver's .resume() routine, it will timeout and eventually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) fail, because the user land process that should respond to the request is frozen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) at this point. So, seemingly, the failure is due to the freezing of tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) Suppose, however, that the firmware file is located on a filesystem accessible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) only through another device that hasn't been resumed yet. In that case,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) request_firmware() will fail regardless of whether or not the freezing of tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) is used. Consequently, the problem is not really related to the freezing of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) tasks, since it generally exists anyway.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) A driver must have all firmwares it may need in RAM before suspend() is called.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) If keeping them is not practical, for example due to their size, they must be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) requested early enough using the suspend notifier API described in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Documentation/driver-api/pm/notifiers.rst.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) VI. Are there any precautions to be taken to prevent freezing failures?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) =======================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) Yes, there are.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) First of all, grabbing the 'system_transition_mutex' lock to mutually exclude a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) piece of code from system-wide sleep such as suspend/hibernation is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) encouraged. If possible, that piece of code must instead hook onto the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) suspend/hibernation notifiers to achieve mutual exclusion. Look at the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) CPU-Hotplug code (kernel/cpu.c) for an example.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) However, if that is not feasible, and grabbing 'system_transition_mutex' is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) deemed necessary, it is strongly discouraged to directly call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) mutex_[un]lock(&system_transition_mutex) since that could lead to freezing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) failures, because if the suspend/hibernate code successfully acquired the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) 'system_transition_mutex' lock, and hence that other entity failed to acquire
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) the lock, then that task would get blocked in TASK_UNINTERRUPTIBLE state. As a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) consequence, the freezer would not be able to freeze that task, leading to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) freezing failure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) However, the [un]lock_system_sleep() APIs are safe to use in this scenario,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) since they ask the freezer to skip freezing this task, since it is anyway
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) "frozen enough" as it is blocked on 'system_transition_mutex', which will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) released only after the entire suspend/hibernation sequence is complete. So, to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) summarize, use [un]lock_system_sleep() instead of directly using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) mutex_[un]lock(&system_transition_mutex). That would prevent freezing failures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) V. Miscellaneous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) /sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) all user space processes or all freezable kernel threads, in unit of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) millisecond. The default value is 20000, with range of unsigned integer.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags