On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com> wrote: > On (06/22/18 22:06), Tetsuo Handa wrote: >> > >> > 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.gr10...@dhcp22.suse.cz ). >> Since OOM killer code is serialized by oom_lock, we can use static buffer for >> OOM killer messages. > > I'm not the right guy to answer this question. Sorry. We need to Cc MM > people on this. > > Does OOM's pr_cont() usage cause too much disturbance to syzkaller? I thought > that OOM was slightly out of sight.
Hard to tell. Nothing specific comes to mind. We do see lines like these: BUG: unable to handle kernel [ 110.NUM] device gre0 entered promiscuous mode BUG:--------[ cut here ]------------ and frequently it's also required to look deep inside of crash message to understand what they really mean. Hard to tell how random pr_cont's contribute to the problem. We now throw away everything that looks any corrupted right away. I guess the main requirement is that the crash report itself does not use pr_cont and provided we have task/cpu context we can separate the crash report lines from everything else (assuming that random pr_cont's on other CPUs won't glue to the report lines).
