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