Hi Johan,
On 06/10/2021 05:10, Johan Hovold wrote:
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?
Yes, after applying only your patch I no longer get the lockdep
splat. I have replied with my Tested-by, thanks.
