On 2018/06/20 22:06, Sergey Senozhatsky wrote: > On (06/20/18 13:32), Dmitry Vyukov wrote: >>> So, if we could get rid of pr_cont() from the most important parts >>> (instruction dumps, etc) then I would just vote to leave pr_cont() >>> alone and avoid any handling of it in printk context tracking. Simply >>> because we wouldn't care about pr_cont(). This also could simplify >>> Tetsuo's patch significantly. >> >> Sounds good to me. > > Awesome. If you and Fengguang can combine forces and lead the > whole thing towards "we couldn't care of pr_cont() less", it > would be really huuuuuge. Go for it! Can't we have seq_printf()-like one which flushes automatically upon seeing '\n' or buffer full? Printing memory information is using a lot of pr_cont(), even in function names (e.g. http://lkml.kernel.org/r/20180622083949.GR10465@xxxxxxxxxxxxxx ). Since OOM killer code is serialized by oom_lock, we can use static buffer for OOM killer messages.
