Re: [PATCH printk v4 00/14] fix console flushing

Petr Mladek
2024-02-07T16:18:39Z

On Wed 2024-02-07 14:46:49, John Ogness wrote:
> Hi,
>
> While testing various flushing scenarios, I stumbled on a few
> issues that cause console flushing to fail. While at LPC2023 in
> Richmond, I sat down with Petr Mladek and we reviewed the
> v2 [0] series. This series is the result of that offline
> discussion. v3 is here [1].
>
> This series addresses the following issues:
>
> 1. The prb_next_seq() optimization caused inconsistent return
> values. Fix prb_next_seq() to the originally intended
> behavior but keep an optimization.
>
> 2. pr_flush() might not wait until the most recently stored
> printk() message if non-finalized records precede it. Fix
> pr_flush() to wait for all records to print that are at
> least reserved at the time of the call.
>
> 3. In panic, the panic messages will not print if non-finalized
> records precede them. Add a special condition so that
> readers on the panic CPU will drop records that are not in
> a consistent state.
>
> 4. It is possible (and easy to reproduce) a scenario where the
> console on the panic CPU hands over to a waiter of a stopped
> CPU. Do not use the handover feature in panic.
>
> 5. If messages are being dropped during panic, non-panic CPUs
> are silenced. But by then it is already too late and most
> likely the panic messages have been dropped. Change the
> non-panic CPU silencing logic to _immediately_ silence
> non-panic CPUs during panic. This also leads to clean panic
> output when many CPUs are blasting the kernel log.
>
> 6. If a panic occurs in a context where printk() calls defer
> printing (NMI or printk_safe section), the printing of the
> final panic messages rely on irq_work. If that mechanism is
> not available, the final panic messages are not seen (even
> though they are finalized in the ringbuffer). Add one last
> explicit flush after all printk() calls are finished to
> ensure all available messages in the kernel log are printed.
>
> 7. When dumping the stacktrace from panic(), do not use the
> printk_cpu_sync because it can deadlock if another CPU holds
> and is unable to release the printk_cpu_sync.
>
> This series also performs some minor cleanups to remove open
> coded checks about the panic context and improve documentation
> language regarding data-less records.
>
> Because of multiple refactoring done in recent history, it
> would be helpful to provide the LTS maintainers with the proper
> backported patches. I am happy to do this.

The series seems to be ready linux-next from my POV. I am going
to push it there so that it gets as much testing before
the merge window as possible.

Best Regards,
Petr