linux-kernel - Re: [PATCH 2/2] printk: Remember the message level for multi-line output

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Apr 2008 12:26:34 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Nick Andrew <nick@...k-andrew.net>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, joe@...ches.com
Subject: Re: [PATCH 2/2] printk: Remember the message level for multi-line
	output


* Nick Andrew <nick@...k-andrew.net> wrote:

> > i've applied this too for testing.
> > 
> > but multi-line strings are a bit unclean i think: each message line 
> > should have its separate printk.
> 
> You'd think. But there are a lot of calls to printk() with multi-line 
> format strings; developers clearly expect it to "just work" and that a 
> message level set at the start will be retained across lines.

ok :-)

> > will your patch leave the behavior of multiple calls to printk alone? 
> > I.e. if i do:
> > 
> >   printk(KERN_ALERT "Danger Will Robinson!\n");
> >   printk("Alien Approaching!\n");
> > 
> > then we'll still get a KERN_ALERT plus a default printk, right?
> 
> Yes, quite. The state of whether we're inside a line is retained 
> across calls to printk (from anywhere in the system) - this allows 
> code like this to usually do what you expect:
> 
> 	printk(KERN_ERR "Error:");
> 	for (i = 0; i < 16; ++i) {
> 		printk("  %02x", i);
> 	}
> 	printk("\n");
> 
> But in your example the first printk call contains a \n at the end of 
> the line and so upon entry to the second printk call the function 
> knows a new line is beginning.

ok - i think your change is a good one.

btw., we could also start emitting debug warnings that the printk is not 
conform. Something like:

  "INFO: the previous printk was done without a KERN_ annotation"

?

	Ingo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/