[PATCH -next] panic: complete the flush of the hard deadlock log messages to the serial port

[PATCH -next] panic: complete the flush of the hard deadlock log messages to the serial port

[Xu Qiang]

when hardlockup_all_cpu_backtrace is on, and there are
a large number of cores in the system, it takes
a long time to output the hard deadlock logs of all cores
to the serial port. When the console_flush_on_panic function
in panic is executed, console_locked is still held.
As a result, garbled characters are displayed in the serial port log.

To solve this problem, wait for a maximum of 10s for the serial port
to be released before console_flush_on_panic.

Signed-off-by: Xu Qiang <xuqiang36@huawei.com>
---
 kernel/panic.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/kernel/panic.c b/kernel/panic.c
index 332736a72a58..0014788e8141 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -301,6 +301,14 @@ void panic(const char *fmt, ...)
 	 * panic() is not being callled from OOPS.
 	 */
 	debug_locks_off();
+
+	/* Wait for all CPUs to complete console_unlock */
+	for (i = 0; i < 10 * 1000; i++) {
+		if (console_trylock())
+			break;
+		mdelay(1);
+	}
+
 	console_flush_on_panic(CONSOLE_FLUSH_PENDING);
 
 	panic_print_sys_info();
-- 
2.25.0

Re: [PATCH -next] panic: complete the flush of the hard deadlock log messages to the serial port

[Andrew Morton]

On Mon, 23 Nov 2020 13:13:59 +0000 Xu Qiang <xuqiang36@huawei.com> wrote:

> when hardlockup_all_cpu_backtrace is on, and there are
> a large number of cores in the system, it takes
> a long time to output the hard deadlock logs of all cores
> to the serial port. When the console_flush_on_panic function
> in panic is executed, console_locked is still held.
> As a result, garbled characters are displayed in the serial port log.
> 
> To solve this problem, wait for a maximum of 10s for the serial port
> to be released before console_flush_on_panic.

Wouldn't it be better to wait until all the printing of all those
backtraces has completed?

Re: [PATCH -next] panic: complete the flush of the hard deadlock log messages to the serial port

[xuqiang (M)]

在 2020/11/24 3:52, Andrew Morton 写道:
> On Mon, 23 Nov 2020 13:13:59 +0000 Xu Qiang <xuqiang36@huawei.com> wrote:
>
>> when hardlockup_all_cpu_backtrace is on, and there are
>> a large number of cores in the system, it takes
>> a long time to output the hard deadlock logs of all cores
>> to the serial port. When the console_flush_on_panic function
>> in panic is executed, console_locked is still held.
>> As a result, garbled characters are displayed in the serial port log.
>>
>> To solve this problem, wait for a maximum of 10s for the serial port
>> to be released before console_flush_on_panic.
> Wouldn't it be better to wait until all the printing of all those
> backtraces has completed?
>
>
> .

The fear that there may be some unexpected abnormal situation,

resulting in the serial port has been occupied without release.


Thanks

         Xu.

Re: [PATCH -next] panic: complete the flush of the hard deadlock log messages to the serial port

[xuqiang (M)]

在 2020/11/24 11:22, xuqiang (M) 写道:
>
> 在 2020/11/24 3:52, Andrew Morton 写道:
>> On Mon, 23 Nov 2020 13:13:59 +0000 Xu Qiang <xuqiang36@huawei.com> 
>> wrote:
>>
>>> when hardlockup_all_cpu_backtrace is on, and there are
>>> a large number of cores in the system, it takes
>>> a long time to output the hard deadlock logs of all cores
>>> to the serial port. When the console_flush_on_panic function
>>> in panic is executed, console_locked is still held.
>>> As a result, garbled characters are displayed in the serial port log.
>>>
>>> To solve this problem, wait for a maximum of 10s for the serial port
>>> to be released before console_flush_on_panic.
>> Wouldn't it be better to wait until all the printing of all those
>> backtraces has completed?
>>
>>
>> .
>
> The fear that there may be some unexpected abnormal situation,
>
> resulting in the serial port has been occupied without release.
>
>
> Thanks
>
>         Xu.
>
Hi, Are there any other questions about this patch?


Thanks

         Xu.