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
