On Fri 2017-01-13 11:52:55, Sergey Senozhatsky wrote: > On (01/12/17 14:10), Petr Mladek wrote: > [..] > > > /** > > > * console_lock - lock the console system for exclusive use. > > > * > > > @@ -2316,7 +2321,7 @@ EXPORT_SYMBOL(console_unlock); > > > */ > > > void __sched console_conditional_schedule(void) > > > { > > > - if (console_may_schedule) > > > + if (get_console_may_schedule()) > > > > Note that console_may_schedule should be zero when > > the console drivers are called. See the following lines in > > console_unlock(): > > > > /* > > * Console drivers are called under logbuf_lock, so > > * @console_may_schedule should be cleared before; however, we may > > * end up dumping a lot of lines, for example, if called from > > * console registration path, and should invoke cond_resched() > > * between lines if allowable. Not doing so can cause a very long > > * scheduling stall on a slow console leading to RCU stall and > > * softlockup warnings which exacerbate the issue with more > > * messages practically incapacitating the system. > > */ > > do_cond_resched = console_may_schedule; > > console_may_schedule = 0; > > > > console drivers are never-ever-ever getting called under logbuf lock. > never. with disabled local IRQs - yes. under logbuf lock - no. that > would soft lockup systems in really bad ways, otherwise. Sure. It is just a misleading comment that someone wrote. I have already fixed this in my patch. > the reason why we set console_may_schedule to zero in > console_unlock() is.... VT. and lf() function in particular. > > commit 78944e549d36673eb6265a2411574e79c28e23dc > Author: Antonino A. Daplas XXXX > Date: Sat Aug 5 12:14:16 2006 -0700 > > [PATCH] vt: printk: Fix framebuffer console triggering might_sleep assertion > > Reported by: Dave Jones > > Whilst printk'ing to both console and serial console, I got this... > (2.6.18rc1) > > BUG: sleeping function called from invalid context at kernel/sched.c:4438 > in_atomic():0, irqs_disabled():1 This is basically the same problem that Testuo has. This commit added the line console_may_schedule = 0; Tetsuo found that we did not clear it when going back via the "again:" goto target. > and we really don't want to cond_resched() when we are in panic. > that's why console_flush_on_panic() sets it to zero explicitly. This actually works even with the bug. console_flush_on_panic() is called with interrupts disabled in panic(). Therefore console_trylock would disable cond_resched. Best Regards, Petr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>