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

Powered by blists - more mailing lists