summaryrefslogtreecommitdiffstats
path: root/fs/dlm/rcom.h
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2022-08-22 13:18:22 +0200
committerPeter Zijlstra <peterz@infradead.org>2022-09-07 21:53:50 +0200
commitf5d39b020809146cc28e6e73369bf8065e0310aa (patch)
tree71d221162d16e53a17b709c83d7e3706c5cbf939 /fs/dlm/rcom.h
parent9963e444f71e671bcbc30d61cf23a2c686ac7d05 (diff)
downloadlinux-f5d39b020809146cc28e6e73369bf8065e0310aa.tar.gz
linux-f5d39b020809146cc28e6e73369bf8065e0310aa.tar.bz2
linux-f5d39b020809146cc28e6e73369bf8065e0310aa.zip
freezer,sched: Rewrite core freezer logic
Rewrite the core freezer to behave better wrt thawing and be simpler in general. By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is ensured frozen tasks stay frozen until thawed and don't randomly wake up early, as is currently possible. As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up two PF_flags (yay!). Specifically; the current scheme works a little like: freezer_do_not_count(); schedule(); freezer_count(); And either the task is blocked, or it lands in try_to_freezer() through freezer_count(). Now, when it is blocked, the freezer considers it frozen and continues. However, on thawing, once pm_freezing is cleared, freezer_count() stops working, and any random/spurious wakeup will let a task run before its time. That is, thawing tries to thaw things in explicit order; kernel threads and workqueues before doing bringing SMP back before userspace etc.. However due to the above mentioned races it is entirely possible for userspace tasks to thaw (by accident) before SMP is back. This can be a fatal problem in asymmetric ISA architectures (eg ARMv9) where the userspace task requires a special CPU to run. As said; replace this with a special task state TASK_FROZEN and add the following state transitions: TASK_FREEZABLE -> TASK_FROZEN __TASK_STOPPED -> TASK_FROZEN __TASK_TRACED -> TASK_FROZEN The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL (IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state is already required to deal with spurious wakeups and the freezer causes one such when thawing the task (since the original state is lost). The special __TASK_{STOPPED,TRACED} states *can* be restored since their canonical state is in ->jobctl. With this, frozen tasks need an explicit TASK_FROZEN wakeup and are free of undue (early / spurious) wakeups. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ingo Molnar <mingo@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org
Diffstat (limited to 'fs/dlm/rcom.h')
0 files changed, 0 insertions, 0 deletions