linux-kernel - Re: + printk-do-cond_resched-between-lines-while-outputting-to-consoles.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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20151204002945.GA3313@swordfish>
Date:	Fri, 4 Dec 2015 09:29:45 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	tj@...nel.org, akpm@...ux-foundation.org, calvinowens@...com,
	davej@...emonkey.org.uk, jack@...e.com, kyle@...nel.org,
	stable@...r.kernel.org, mm-commits@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: +
 printk-do-cond_resched-between-lines-while-outputting-to-consoles.patch
 added to -mm tree

On (12/03/15 10:57), Jan Kara wrote:
[..]
> > > CPU2 still can cause lots of troubles. consider
> > > 
> > > CPU0		CPU1			CPU2
> > > printk		
> > > ...		printk_deferred		
> > > printk					wake_up_klogd
> > > 						wake_up_klogd_work_func
> > > 							console_trylock
> > > 								console_unlock
> > > 
> > > printk_deferred() may be issued by scheduler, for example.
> > 
> > IOW, may be we can start limiting the number of bytes printed in console_unlock()
> > from irq contexts. Which is quite ugly, yes. We basically don't know how much time
> > we spend in call_console_drivers(); some of the consoles can do 'internal' spin_lock
> > loops in ->write() handlers, etc. So something like this (below) probably will not
> > really help, but still it's not always OK to do `while (1)' loop in console_unlock()
> > for irqs.
> 
> What we really want is pushing the printing into async context (unless
> forced by debug option or oops in progress). Because what you do here fixes
> only a small fraction of the problem space. I have patches which fix more
> of it (https://lkml.org/lkml/2015/10/26/16) but they are still not enough
> because on large machines e.g. udev times out because printing messages
> about inserted hardware over serial console just takes too long.

absolutely agree. thanks for the link!

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