On (11/08/18 20:37), Tetsuo Handa wrote: > On 2018/11/08 13:45, Sergey Senozhatsky wrote: > > So, can we just do the following? /* a sketch */ > > > > lockdep.c > > printk_safe_enter_irqsave(flags); > > lockdep_report(); > > printk_safe_exit_irqrestore(flags); > > If buffer size were large enough to hold messages from out_of_memory(), > I would like to use it for out_of_memory() because delaying SIGKILL > due to waiting for printk() to complete is not good. Surely we can't > hold all messages because amount from dump_tasks() is unpredictable. > Maybe we can hold all messages from dump_header() except dump_tasks(). > > But isn't it essentially same with > http://lkml.kernel.org/r/1493560477-3016-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx > which Linus does not want? Dunno. I guess we still haven't heard from Linus because he did quite a good job setting up his 'email filters' ;) Converting the existing users to buffered printk is not so simple. Apparently there are different paths; some can afford buffered printk, some cannot. Some of 'cont' users tend to get advantage of transparent 'cont' context: start 'cont' output in function A: A()->pr_cont(), continue it in B: A()->B()->pr_cont(), and then in C: A()->B()->C()->pr_cont(), and finally flush in A: A()->pr_cont(\n). And then some paths have the early_printk requirement. We can break the 'transparent cont' by passing buffer pointers around [it can get a bit hairy; looking at lockdep patch], but early_printk requirement is a different beast. So in my email I was not advertising printk_safe as a "buffered printk for everyone", I was just talking about lockdep. It's a bit doubtful that Peter will ACK lockdep transition to buffered printk. -ss
