Hello, Jookia, le ven. 13 mars 2020 13:22:37 +1100, a ecrit: > I was debugging the big deadlock that's fixed in staging-next when I hit > this backtrace. Anybody have any ideas on what's going on here? > Possible unsafe locking scenario:\x0a > CPU0 > ---- > lock(console_lock); > <Interrupt> > lock(console_lock); Which is possible indeed. > lock_acquire+0x13f/0x370 > ? speakup_clear_selection+0xe/0x20 [speakup] > console_lock+0x33/0x50 > ? speakup_clear_selection+0xe/0x20 [speakup] > speakup_clear_selection+0xe/0x20 [speakup] > speakup_cut+0x19e/0x4b0 [speakup] [...] > i8042_interrupt+0x232/0x510 [i8042] speakup_cut, called from the keyboard interrupt handler, calls speakup_clear_selection which takes a lock. That can't be safe since interrupt handlers can't sleep. I guess the speakup_clear_selection call in speakup_cut should be moved into speakup's set_selection mechanism, i.e. inside __speakup_set_selection. And actually just get rid of speakup_clear_selection and simply put clear_selection just before set_selection_kernel inside __speakup_set_selection. Samuel _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
