Re: [PATCH v3 2/2] Handle flushing of CPU backtraces during panic

[John Ogness]

On 2024-08-21, takakura@xxxxxxxxxxxxx wrote:
>>> /**
>>>  * console_try_or_trigger_flush - try to flush consoles directly when
>>>  *   safe or the trigger deferred flush.
>>>  *
>>>  * Context: Any
>>>  */
>>> void console_try_or_trigger_flush(void)
>>> {
>>>      if (!is_printk_legacy_deferred() && console_trylock())
>>>              console_unlock();
>>>      else
>>>              defer_console_output();
>>> }
>>>
>>> and use it instead of printk_trigger_flush() in
>>> nmi_trigger_cpumask_backtrace().
>>
>> Just to be clear, you are talking about removing
>> printk_trigger_flush() entirely and instead provide the new
>> console_try_or_trigger_flush()?  Which then also involves updating
>> the call sites:
>>
>> lib/nmi_backtrace.c:nmi_trigger_cpumask_backtrace()
>> arch/powerpc/kernel/watchdog.c:watchdog_timer_interrupt()
>>
>
> Taking a look at [0], in addition to the mentioned call sites, 
> nbcon_device_release() will also be calling printk_trigger_flush()?
> For nbcon_device_release(), I thought its better not to be replaced as 
> it calles for @legacy_off, in which case printk_trigger_flush() seems 
> more suitable as it always defers printing.

The @legacy_off logic would be within console_try_or_trigger_flush(),
so the result would be the same.

> Also taking a look at the [1], for nmi_trigger_cpumask_backtrace(), 
> I thought that it will not comply with the syncing of 
> legacy_allow_panic_sync. I believe it will allow flushing of legacy consoles 
> before printk_legacy_allow_panic_sync() which is out of sync.

But isn't your patch also causing that violation?

printk_legacy_allow_panic_sync() performs a trylock/unlock. Isn't that
good enough?

John