Re: [RFC PATCH] printk: Introduce "store now but print later" prefix.

[Petr Mladek <pmladek@suse.com>]

On Thu 2019-03-07 03:24:25, Tetsuo Handa wrote:
> On 2019/03/06 19:04, Petr Mladek wrote:
> >> I'm suggesting to use a non-async printk() for $trailer_text_line line. I think
> >> that changing all printk() called from out_of_memory() to async is doable, if
> >> the caller of out_of_memory() wakes up a dedicated kthread described below.
> > 
> > This is error prone. The trailing printk is not guaranteed:
> > 
> >     + It might get lost by code refactoring.
> 
> Caller uses this async printk() with their own risk. This concern is same with
> "buffering into on-stack 'char buf[80]' using snprintf() and forgetting to flush
> it using printk()".

AFAIK, all pr_cont() users are self-contained. Most of them print all
pieces in the same function. Some of them print the part of the lines
using some helper scripts but these are defined in the same source
file, usually right above the caller.

> > 
> >     + People would miss that it is needed when async printk is used
> >       in a shared function, e.g. dump_stack().
> 
> I'm planning to allow async printk() for shared functions like dump_stack()
> because there will be some $trailer_text_line line after such shared functions.
> (By the way, for that reason, I expect that we won't do a tree-wide KERN_DEFAULT
> removal so that callers can pass KERN_DEFAULT_ASYNC as an function argument to
> such shared functions.)

Now, you are going to spread related lines all over the kernel sources.


> > But I would really like to avoid even more printk variants.
> > They have many problems:
> > 
> >     + Only a handful of people would know how to use them right.
> 
> The caller of async printk() knows when/how to use async printk().
> 
> > 
> >     + They are hard to maintain. Any incompatible printk() in the call
> >       chain might break the intention.
> 
> There is no incompatible printk(). Only when to wake up a thread which
> writes to consoles differs.

By incompatible I mean the following:

   + Adding any synchronous printk() into a chain of async printk's
     will break the chain. I mean that the consoles will get handled
     by the new normal printk() before the original author wanted.

   + Also the wanted normal printk() might get removed from some
     reason (by mistake). Then all the previous async lines will
     not get reliably flushed.

Both situations are bugs that might get fixed. But the API
is just too error prone from my POV.

We are repeating the same arguments by different words all over
again. I explained why the API is not acceptable for me and
suggested other approaches. This is my last mail about the API.

Best Regards,
Petr