Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

[Tetsuo Handa]

On 2018/11/28 22:29, David Laight wrote:
> I also spent a week trying to work out why a customer kernel was
> locking up - only to finally find out that the distro they were
> using set 'panic on opps' - making it almost impossible to find
> out what was happening.

How can line buffering negatively affect this case? The current thread
which triggered an oops will keep calling printk() until that current
thread reaches panic(), won't it?

The only case where line buffering negatively affects will be that the
initial 10 bytes of a critical line failed to reach log_store() because
some other thread (not the current thread doing a series of printk())
halted CPUs / reset the whole machine _before_ the initial 10 bytes of
a critical line reaches log_store().



On 2018/11/26 13:34, Sergey Senozhatsky wrote:
> Or... Instead.
> We can just leave pr_cont() alone for now. And make it possible to
> reconstruct messages - IOW, inject some info to printk messages. We
> do this at Samsung (inject CPU number at the beginning of every
> message. `cat serial.0 | grep "\[1\]"` to grep for all messages from
> CPU1). Probably this would be the simplest thing.

Yes, I sent a patch which helps reconstructing messages at
http://lkml.kernel.org/r/1543045075-3008-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx .