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: <20080811114243.GO9038@one.firstfloor.org>
Date:	Mon, 11 Aug 2008 13:42:43 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	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

On Mon, Aug 11, 2008 at 01:22:06PM +0200, Peter Zijlstra wrote:
> You only loose the msgs with klogd, console still gets everything. If
> firewalls are generating that much data, perhaps its time to think about
> alternative ways to channel that.

Yes, and netfilter has them in fact, but it's clearly still a regression for 
people who rely on klogd for this today.

Also firewall is just an example. Other cases might be people relying
on these selinux messages. Or some other kernel messages.

> 
> > 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.
> 
> Depends, I don't give a rats arse about klogd - I get everything through
> serial onto another machine. 

The question of interest is not how you personally configure your systems, 
but what the userbase uses.

> > 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?
> 
> Why not fix it if its acceptable - the deadlock is just ugly.

Well you fix one thing and you break another thing (high rate
printk). It's not clear to me that the trade off is a good
one in this case. I suppose far more people care about
high rate printk than the number of people who put
printk into the scheduler.

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