Hi Dave, On 2023-10-16, Dave Young <dyoung@xxxxxxxxxx> wrote: >> > Does anyone really want explicit flushes in panic()? >> >> So far you are the only one speaking against it. I expect as time >> goes on it will get even more complex as it becomes tunable (also >> something we talked about during the demo). > > Flush consoles in panic kexec case sounds not good, but I have no deep > understanding about the atomic printk series, added kexec list and > reviewers in cc. Currently every printk() message tries to flush immediately. This series introduced a new method of first allowing a set of printk() messages to be stored to the ringbuffer and then flushing the full set. That is what this discussion was about. The issue with allowing a set of printk() messages to be stored is that you need to explicitly mark in code where the actual flushing should occur. Petr's argument is that we do not want to insert "flush points" into the panic() function and instead we should do as we do now: flush each printk() message immediately. In the end (for my upcoming v3 series) I agreed with Petr. We will continue to keep things as they are now: flush each printk() message immediately. Currently consoles try to flush unsafely before kexec. With the atomic printk series our goal is to only perform _safe_ flushing until all other panic operations are complete. Only at the very end of panic() would unsafe flushing be attempted. John _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
