On Fri 2017-01-13 12:53:07, Sergey Senozhatsky wrote: > On (01/13/17 11:52), Sergey Senozhatsky wrote: > [..] > > 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. > > > > console_trylock() checks oops_in_progress, so re-taking the semaphore > > when we are in > > > > panic() > > console_flush_on_panic() > > console_unlock() > > console_trylock() > > > > should be OK. as well as doing get_console_conditional_schedule() somewhere > > in console driver code. > > d'oh... no, this is false. console_flush_on_panic() is called after we > bust_spinlocks(0), BUT with local IRQs disabled. so console_trylock() > would still set console_may_schedule to 0. Ah, you found it yourself. Best Regards, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
