Re: [PATCH] printk: inject caller information into the body of message

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

Hi Dmitry,

On (06/20/18 10:45), Dmitry Vyukov wrote:
> Hi Sergey,
> 
> What are the visible differences between this patch and Tetsuo's
> patch?

I guess none, and looking at your requirements below I tend to agree
that Tetsuo's approach is probably what you need at the end of the day.

> The only thing that will matter for syzkaller parsing in the
> end is the resulting text format as it appears on console. But you say
> "I'm not pushing for this particular message format", so what exactly
> do you want me to provide feedback on?
> I guess we need to handle pr_cont properly whatever approach we take.

Mostly, was wondering about if:
a) you need pr_cont() handling
b) you need printk_safe() handling

The reasons I left those things behind:

a) pr_cont() is officially hated. It was never supposed to be used
   on SMP systems. So I wasn't sure if we need all that effort and
   add tricky code to handle pr_cont(). Given that syzkaller is
   probably the only user of that functionality.

b) printk_safe output is quite uncommon. And we flush per-CPU buffer
   from the same CPU which has caused printk_safe output [except for
   panic() flush] therefore logging the info available to log_store()
   seemed enough. IOW, once again, was a bit unsure if we want to add
   some complex code to already complex code, with just one potential
   user.

To summarize, I was just wondering where is the waterline: can a small
patch make you happy, or do you need a big one.

> Re format, for us it would be much more convenient if the context is a
> single token that can be used as is, say "T<pid>" for task context,
> "I<cpu>" for interrupts, "N<cpu>" for nmi's

Got it.

	-ss