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

From: Petr Mladek
Date: Tue Oct 09 2018 - 04:40:04 EST


On Tue 2018-10-02 11:38:35, Sergey Senozhatsky wrote:
> From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
>
> 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@xxxxxxxxx>
> ---
> 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