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: <20131116113506.GA30605@amd.pavel.ucw.cz>
Date:	Sat, 16 Nov 2013 12:35:06 +0100
From:	Pavel Machek <pavel@....cz>
To:	Jan Kara <jack@...e.cz>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 3/4] printk: Defer printing to irq work when we printed
 too much

Hi!

> > > > > Reviewed-by: Steven Rostedt <rostedt@...dmis.org>
> > > > > Signed-off-by: Jan Kara <jack@...e.cz>
> > > > 
> > > > When a message takes tens of seconds to be printed, it usually means
> > > > we are in trouble somehow :)
> > > > I wonder what printk source can trigger such a high volume.
> > >   Machines with tens of processors and thousands of scsi devices. When
> > > device discovery happens on boot, all processors are busily reporting new
> > > scsi devices and one poor looser is bound to do the printing for ever and
> > > ever until the machine dies...
> > 
> > Dunno. In these cases, would it make sense to:
> > 
> > 1) reduce amount of text printed
>   I thought about this as well. But
> a) It doesn't seem practical as you would have to modify lots of drivers
>    and keep them rather silent. That seems rather fragile. Plus you will
>    not display some potentially useful information.
> b) It doesn't address the real underlying problem that the way printk() is
>    currently implemented, there is no bound on the time CPU spends in the
>    loop printing from buffer to console. And the fact that this loop
>    sometimes happens with interrupts disabled makes the situation even
>    worse.
>  
> > 2) just print [XXX characters lost] on overruns?
>   We don't overrun the printk buffer so no characters are lost. It just
> takes too long to feed the whole printk buffer through serial console...

Yes, I know. No characters are lost, but we spend seconds with
interrupts disabled, breaking the system. (SCSI timeouts? We do
keyboard autorepeat in software these days...)

Would it be better to just drop the characters?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ