linux-kernel - Re: [PATCH v3] printk: Have printk() never buffer its data

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:	Tue, 26 Jun 2012 02:56:18 +0200
From:	Kay Sievers <kay@...y.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Joe Perches <joe@...ches.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>
Subject: Re: [PATCH v3] printk: Have printk() never buffer its data

On Tue, Jun 26, 2012 at 2:40 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Jun 25, 2012 at 5:23 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
>>
>> Ok, but I thought you wanted the "properly handle continuations" that we
>> now have in the kernel.  I must be mistaken.
>
> We had that before too. It has nothing to do with merging the data,
> and the problem was just an outright *bug* in the initial record-based
> implementation. Nothing to do with buffering.
>
> Line continuations should happen if the previous printk didn't end
> with a '\n', and if the next one doesn't have a level. That was always
> the rule. It's a simple rule, and it works.
>
> Now, we can (and Key did) tweak the rule a little bit for cases that
> never actually happen in practice.
>
> So sure, add the "we only continue on the same line if we're the same
> process as the last process that did the printk" rule to the above
> rule. In practice it really doesn't matter, since partial lines are
> rare to begin with. And taking interrupt depth into account is another
> nice tweak. But it's a tweak, it's not important. Nobody really cares,
> but you can try to do a bit better.
>
> And none of the above has to do with *buffering*. The above rules are
> 100% the same whether you buffer or not.
>
> Sure, with buffering, you can handle the insane cases and try to get
> interspersed partial lines to do the right thing. And Kay did that.
> And it turns out to (a) never matter and (b) cause problems for
> debugging. So just saying "stop doing it" is the no-brainer solution.
> Don't buffer printouts to the display, because bad things may happen
> before the buffer is flushed.

Buffering has nice effects though:
It makes continuation lines appear as one record in the buffer, not as
n individual prints with n headers.

It fully isolates the race-sensitive continuation print users from the
normal terminated print users. With buffering, races against each
other are a lot more unlikely to happen, because the normal terminated
line prints never affect the sensitive continuation users, and we
would need two racy continuation users to race against each other. And
we did see the interleaving all the time with the old printk.

Here is what our test module has produced. And that could only be
achieved by doing buffering:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c313af145b9bc4fb8e8e0c83b8cfc10e1b894a50

I'm not arguing anymore, but I have to defend that buffering produces
far better results than without. Granted, besides for continuation
users that crash the kernel and want to see the partial line they
printed.

Kay
--
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/