On Fri, Oct 01, 2021 at 11:15:33PM -0300, Fabio Estevam wrote:
> On 01/10/2021 10:56, Johan Hovold wrote:
>
> > No, no, no.
> >
> > Just replace this unlock with uart_unlock_and_check_sysrq() and do the
> > corresponding change in imx_uart_int(). The result is an even smaller
> > diff than what you're currently proposing and without any performance
> > penalty from dropping and reacquiring the lock.
>
> Just to be clear, this is something that I have also tried:
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 8b121cd869e9..b652908f0bf1 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -803,7 +803,7 @@ static irqreturn_t __imx_uart_rxint(int irq, void
> *dev_id)
> continue;
> }
>
> - if (uart_handle_sysrq_char(&sport->port, (unsigned char)rx))
> + if (uart_prepare_sysrq_char(&sport->port, (unsigned char)rx))
> continue;
>
> if (unlikely(rx & URXD_ERR)) {
> @@ -858,7 +858,7 @@ static irqreturn_t imx_uart_rxint(int irq, void
> *dev_id)
>
> ret = __imx_uart_rxint(irq, dev_id);
>
> - spin_unlock(&sport->port.lock);
> + uart_unlock_and_check_sysrq(&sport->port);
>
> return ret;
> }
> @@ -991,7 +991,7 @@ static irqreturn_t imx_uart_int(int irq, void
> *dev_id)
> ret = IRQ_HANDLED;
> }
>
> - spin_unlock(&sport->port.lock);
> + uart_unlock_and_check_sysrq(&sport->port);
>
> return ret;
> }
> , but still get the lockdep warning in this case.
Ok, thanks for testing. The above is what I meant and it does fix the
false-positive lockdep splat which motivated
uart_unlock_and_check_sysrq() to be added in the first place.
Looking closer at the splat you reported (which you've edited quite
heavily), it becomes apparent that you are now hitting a different
locking issue. And it's not a false positive this time.
There a problem with the workqueue debugging code, which unless fixed at
the source, would prevent any console driver from queueing work while
holding a lock also taken in their write paths. And
tty_flip_buffer_push() is just one example of many.
I can easily reproduce the splat with another serial driver, and I've
also been able to trigger the actual deadlock.
I've prepared a patch that takes care of the workqueue state dumping,
which I'll send as a reply to this mail. Would you mind giving it a spin
with the imx driver as well?
Note that you may hit the other, false-positive, lockdep splat when
running with the workqueue fix, but the above diff should then address
that.
Johan
