Messages in this thread | | | Date | Wed, 7 Feb 2024 17:18:36 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH printk v4 00/14] fix console flushing |
| |
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
| |