Messages in this thread | | | From | Dmitry Vyukov <> | Date | Mon, 25 Jun 2018 11:36:17 +0200 | Subject | Re: [PATCH] printk: inject caller information into the body of message |
| |
On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky <sergey.senozhatsky.work@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.GR10465@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).
| |