New deadlock?

[Samuel Thibault]

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