linux-kernel - Re: + printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch added to -mm tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140507095850.GC18456@arm.com>
Date:	Wed, 7 May 2014 10:58:50 +0100
From:	Will Deacon <will.deacon@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jan Kara <jack@...e.cz>,
	"mm-commits@...r.kernel.org" <mm-commits@...r.kernel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"kay@...y.org" <kay@...y.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: +
 printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch
 added to -mm tree

On Tue, May 06, 2014 at 11:05:53PM +0100, Andrew Morton wrote:
> On Tue, 6 May 2014 14:12:34 +0100 Will Deacon <will.deacon@....com> wrote:
> > > > > My opinion is that when you are printing from each and every interrupt
> > > > > which happens so often, then you have a problem and disabling IRQs in
> > > > > printk so that your interrupt doesn't happen that often seems like a poor
> > > > > solution to me. You could as well just ratelimit your debug messages,
> > > > > couldn't you?
> > > > 
> > > > My use-case was basically using printk as a debug trace during early boot
> > > > when bringing up Linux on a new CPU core. I don't think ratelimiting would
> > > > be the right thing there, since I really did want as many messages to
> > > > reach the console as possible (which is also why I wrote this patch, not
> > > > just the other one in the series).
> > >   OK, I understand. It just seems wrong to me to throttle all interrupts on
> > > the cpu while doing printing just because someone might be doing debug
> > > printing from the interrupt. Sure it's fine as a debug hack but on a
> > > production machine that seems rather counterproductive.
> > 
> > Perhaps, but the one time I *really* want printk to be reliable is when I'm
> > using it to debug a problem.
> 
> If you're debugging a problem, you're able to alter printk!  So perhaps
> one way out of this is some developer-only ifdef to robustify printk
> for particular usage patterns.

Possibly, but I fear we'd incur the wrath of Alan after reading that other
thread. Having a CONFIG_ option or similar to control the amount of printing
we do is very similar to the command-line option Jan proposed in his series.

So, sadly, I think we may as well drop this patch for the time being. The
second patch in the series still applies fine without it and means we can
at least detect when we're dropping messages.

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