Messages in this thread | | | Date | Wed, 7 Feb 2024 17:53:23 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH printk v4 00/14] fix console flushing |
| |
On Wed 2024-02-07 17:18:38, Petr Mladek wrote: > 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.
JFYI, it has been committed into printk/linux.git, branch rework/console-flushing-fixes.
Let's keep our fingers crossed.
Best Regards, Petr
| |