linux-kernel - Re: [PATCH] printk: robustify printk

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]

Message-ID: <87zlnj24qc.fsf@basil.nowhere.org>
Date:	Mon, 11 Aug 2008 13:03:39 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, tglx@...utronix.de,
	marcin.slusarz@...il.com, linux-kernel@...r.kernel.org,
	davem@...emloft.net, rostedt@...dmis.org,
	paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH] printk: robustify printk

Ingo Molnar <mingo@...e.hu> writes:

> * Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
>> On Fri, 2008-08-08 at 21:21 +0200, Peter Zijlstra wrote:
>> 
>> > The initial printk_tick() based implementation didn't suffer this
>> > problem, should we revert to that scheme?
>> 
>> Just in case people care..
>> 
>> ---
>> Subject: printk: robustify printk
>> 
>> Avoid deadlocks against rq->lock and xtime_lock by deferring the klogd 
>> wakeup by polling from the timer tick.
>
> i missed most of the discussion, but this seems like the simplest (and 
> hence ultimately the best) approach to me.

The problem is that it means any printk data output that is more
than DMESG-BUFFER-SIZE bytes during one clock tick is going to lose data.
It loses the natural adaption to higher printk rates that you
got previously.

Now we could say that for debugging etc. people should switch
to other mechanisms like relayfs, but I would still worry about
some corner cases where losing printk data that wasn't lost before
could be a severe regression (e.g. consider firewall log messages
or similar)

Essentially it makes printk (much?) less reliable than it was before
in the general case. Not sure that's a good thing. So the patch
title is definitely misleading.

As Linus pointed out earlier we've survived with this restriction
(not doing printk in the scheduler) for a long time, so is there
really a that pressing need to change that?

> Coupling printk with RCU, albeit elegant, does not seem like the right 
> choice to me in this specific case: printk as an essential debug 
> mechanism should be as decoupled as possible.

RCU coupling has actually the same problem.

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