On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > console_trylock, called from within printk, can be called from pretty > much anywhere. Including try_to_wake_up. Note that this isn't common, > usually the box is in pretty bad shape at that point already. But it > really doesn't help when then lockdep jumps in and spams the logs, > potentially obscuring the real backtrace we're really interested in. > One case I've seen (slightly simplified backtrace): > > Call Trace: > <IRQ> > console_trylock+0xe/0x60 > vprintk_emit+0xf1/0x320 > printk+0x4d/0x69 > __warn_printk+0x46/0x90 > native_smp_send_reschedule+0x2f/0x40 > check_preempt_curr+0x81/0xa0 > ttwu_do_wakeup+0x14/0x220 > try_to_wake_up+0x218/0x5f0 try_to_wake_up() takes p->pi_lock. It could deadlock because it can get called recursively from printk_safe_up(). And there are more locks taken from try_to_wake_up(), for example, __task_rq_lock() taken from ttwu_remote(). IMHO, the most reliable solution would be do call the entire up_console_sem() from printk deferred context. We could assign few bytes for this context in the per-CPU printk_deferred variable. Best Regards, Petr _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
