[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231220211640.2023645-1-dianders@chromium.org>
Date: Wed, 20 Dec 2023 13:15:33 -0800
From: Douglas Anderson <dianders@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Petr Mladek <pmladek@...e.com>,
Li Zhe <lizhe.67@...edance.com>,
Pingfan Liu <kernelfans@...il.com>,
John Ogness <john.ogness@...utronix.de>,
Lecopzer Chen <lecopzer.chen@...iatek.com>,
Douglas Anderson <dianders@...omium.org>,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] watchdog: Better handling of concurrent lockups
When we get multiple lockups at roughly the same time, the output in
the kernel logs can be very confusing since the reports about the
lockups end up interleaved in the logs. There is some code in the
kernel to try to handle this but it wasn't that complete.
Li Zhe recently made this a bit better for softlockups (specifically
for the case where `kernel.softlockup_all_cpu_backtrace` is not set)
in commit 9d02330abd3e ("softlockup: serialized softlockup's log"),
but that only handled softlockup reports. Hardlockup reports still had
similar issues.
This series also has a small fix to avoid dumping all stacks a second
time in the case of a panic. This is a bit unrelated to the
interleaving fixes but it does also improve the clarity of lockup
reports.
Douglas Anderson (4):
watchdog/hardlockup: Adopt softlockup logic avoiding double-dumps
watchdog/softlockup: Use printk_cpu_sync_get_irqsave() to serialize
reporting
watchdog/hardlockup: Use printk_cpu_sync_get_irqsave() to serialize
reporting
watchdog: If panicking and we dumped everything, don't re-enable
dumping
kernel/watchdog.c | 43 ++++++++++++++++++++++++++++++++-----------
1 file changed, 32 insertions(+), 11 deletions(-)
--
2.43.0.472.g3155946c3a-goog
Powered by blists - more mailing lists