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 stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html