summaryrefslogtreecommitdiff
path: root/include/ras
diff options
context:
space:
mode:
authorPetr Mladek <pmladek@suse.com>2022-06-15 19:28:05 +0300
committerPetr Mladek <pmladek@suse.com>2022-06-15 23:04:15 +0300
commitb87f02307d3cfbda768520f0687c51ca77e14fc3 (patch)
treeb95087d60c973b8fa365b0a2ab1a49c3e8373451 /include/ras
parentc3230283e2819a69dad2cf7a63143fde8bab8b5c (diff)
downloadlinux-b87f02307d3cfbda768520f0687c51ca77e14fc3.tar.xz
printk: Wait for the global console lock when the system is going down
There are reports that the console kthreads block the global console lock when the system is going down, for example, reboot, panic. First part of the solution was to block kthreads in these problematic system states so they stopped handling newly added messages. Second part of the solution is to wait when for the kthreads when they are actively printing. It solves the problem when a message was printed before the system entered the problematic state and the kthreads managed to step in. A busy waiting has to be used because panic() can be called in any context and in an unknown state of the scheduler. There must be a timeout because the kthread might get stuck or sleeping and never release the lock. The timeout 10s is an arbitrary value inspired by the softlockup timeout. Link: https://lore.kernel.org/r/20220610205038.GA3050413@paulmck-ThinkPad-P17-Gen-1 Link: https://lore.kernel.org/r/CAMdYzYpF4FNTBPZsEFeWRuEwSies36QM_As8osPWZSr2q-viEA@mail.gmail.com Signed-off-by: Petr Mladek <pmladek@suse.com> Tested-by: Paul E. McKenney <paulmck@kernel.org> Link: https://lore.kernel.org/r/20220615162805.27962-3-pmladek@suse.com
Diffstat (limited to 'include/ras')
0 files changed, 0 insertions, 0 deletions