Re: Spinlock in f_midi_transmit causing kernel crash

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-01-29 14:59:19 [-0700], Jillian Donahue wrote:
> > So a simple "tasklet_hi_schedule(&midi->tasklet);" instead of "f_midi_transmit(midi)" in f_midi_complete() might do the trick.
> 
> This fixes the problem - do you have any insight to how this worked in
> the first place? Trying to understand the change.

There are possibilities. The problem is that you send a packet and it
completes the same moment and the completion callback is invoked which
deadlocks.

Now:
- PREEMPT_RT may have moved the timing a bit (makes it behave a bit
  different or simply make a UP device behave like a SMP one) to the
  point that it sees the completion of the request where it did not
  before. So does it occur without PREEMPT_RT?

- It never did work in this combination even without PREEMPT_RT. The
  driver (f_midi) was never tested with the USB device controller you
  have and the one it was tested with behaves differently so the
  recursion never occurred.

- It is an old driver (f_midi). It was never tested on SMP or with
  enabled lock testing. On UP spinlocks end up almost as NOPs so a
  deadlock (as in this case) will not be observed.

Either way I would blame f_midi here.
Once you have the pieces together, mind sending a patch?

Sebastian