linux-kernel - Re: [RFC] printk: More consistent loglevel for continuous lines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 6 Dec 2021 18:34:14 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] printk: More consistent loglevel for continuous lines

On Thu 2021-11-25 09:53:49, Sergey Senozhatsky wrote:
> On (21/11/24 16:48), Petr Mladek wrote:
> > 
> > Anyway, it looks a bit non-practical to update all existing pr_cont()
> > callers:
> > 
> > 	$> git grep "pr_cont" | wc -l
> > 	2054
> 
> Another question is how many pr_cont()-s are getting compiled with
> the "average" production kernel config. A number of pr_cont() is in
> debugging code - lockdep, kasan, etc. - which is not compiled for prod.

It is still >500 for x86_64 default configuration as mentioned in
the reply by Joe.

> Let's assume something like this
> 
> 	foo()
> 	{
> 		char *s;
> 
> 		pr_cont("Blah ");
> 		s = arch_foo();
> 		pr_cont("%s \n", s);
> 	}
> 
> Suppose that arch_foo() errs and pr_warn()-s. Are we going to use WARN
> level for trailing pr_cont()?
> 
> 	pr_cont("Blah ") -> printk_write_loglevel_ctx(default)
> 	pr_warn() -> printk_write_loglevel_ctx(warn)
> 	pr_cont("%s \n"") <- printk_read_loglevel_ctx(warn)

Yes, the proposed solution will not work when there is a nested
message in the same context. It was even mentioned in the commit
message.

But nested messages break the continuous lines completely. They
primary break the text.

pr_cont()/KERN_CONT approach could work reasonably only for
self-contained code. Though even these lines might still get
interleaved by messages from another context/CPU. But it has
a solution. caller_id allows to connect the right pieces.
The proposed patch allows to preserve the loglevel and
actually see all the pieces.

pr_cont()/KERN_CONT is bad API for situations where the pieces
are printed by complicated and/or external code. Such code
should use its own buffer or avoid continuous lines at all.

By other words. The patch solves one fundamental problem when
pr_cont() is used reasonably. It does not help in situations
where pr_cont() should not be used at all.

Best Regards,
Petr