On (11/08/18 12:53), Petr Mladek wrote: > > lockdep.c > > printk_safe_enter_irqsave(flags); > > lockdep_report(); > > printk_safe_exit_irqrestore(flags); > > All this looks nice. Let's look it also from the other side. > The following comes to my mind: > > a) lockdep is not the only place when continuous lines get mixed. > This patch mentions also RCU stalls. The other patch mentions > OOM. I am sure that there will be more. > > b) It is not obvious where printk_safe() would be necessary. > While buffered printk is clearly connected with continuous > lines. > > c) I am not sure that disabling preemption would always be > acceptable. > > d) We might need to increase the size of the per-CPU buffers if > they are used more widely. > > e) People would need to learn a new (printk_safe) API when it is > use outside printk sources. > > f) Losing the entire log is more painful than loosing one line > when the buffer never gets flushed. > > Sigh, no solution is perfect. If only we could agree that one > way was better than the other. I agree with what you are saying. All of the above (in my email) was for lockdep only, that's why I did mention lockdep several times. Like I said, a random and wild idea. I'm not proposing printk_safe as a "better" buffered printk for everyone. The buffered_printk patch is pretty big, and comes with a price tag. If lockdep and OOM people will ACK buffered printk transition in its current form, then we can go ahead. It's debatable if we need a fixed size list of buffers; or we can do kmalloc()+cont fallback. But if we will have ACKs, then we can move forward. -ss
