Re: [RFC][PATCH 2/3] printk: lock/unlock console only for new logbuf entries

[Petr Mladek <pmladek@suse.com>]

On Tue 2018-10-02 11:38:35, Sergey Senozhatsky wrote:
> From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> 
> Prior to 5c2992ee7fd8a29 ("printk: remove console flushing special
> cases for partial buffered lines") we would do console_cont_flush()
> for each pr_cont() to print cont fragments, so console_unlock() would
> actually print data:
> 
> 	pr_cont();
> 	 console_lock();
> 	 console_unlock()
> 	  console_cont_flush(); // print cont fragment
> 	...
> 	pr_cont();
> 	 console_lock();
> 	 console_unlock()
> 	  console_cont_flush(); // print cont fragment
> 
> We don't do console_cont_flush() anymore, so when we do pr_cont()
> console_unlock() does nothing (unless we flushed the cont buffer):
> 
> 	pr_cont();
> 	 console_lock();
> 	 console_unlock();      // noop
> 	...
> 	pr_cont();
> 	 console_lock();
> 	 console_unlock();      // noop
> 	...
> 	pr_cont();
> 	  cont_flush();
> 	    console_lock();
> 	    console_unlock();   // print data
> 
> We also wakeup klogd purposelessly for pr_cont() output - un-flushed
> cont buffer is not stored in log_buf; there is nothing to pull.
> 
> Thus we can console_lock()/console_unlock()/wake_up_klogd() only when
> we know that we log_store()-ed a message and there is something to
> print to the consoles/syslog.
> 
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> ---
>  kernel/printk/printk.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

The patch makes perfect sense. It looks a bit hacky but I can't
think about any less hacky one.

I wonder if it is worth it. But if nobody else is against it
I am going to push it.

I just hope that we will get rid of it with the buffered printk
rather sooner than later.

Best Regards,
Petr