> 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. On Wed, Jan 29, 2025 at 3:39 AM Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > On 2025-01-24 15:21:21 [-0700], Jillian Donahue wrote: > … > > I have tried the proposed fixes and cherry-picked commits c7d9efdff68e > > and 8653d71ce376 (the equivalent fix in f_midi.c), and upgraded to > > v5.10rt. I still see the spin lock in both cases but the trace is > > slightly different: > > > > [ 193.010603] kernel BUG at /kernel-source//kernel/locking/rtmutex.c:1048! > > This means the caller already owns the lock it asked for. > > > [ 193.010609] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > > [ 193.010644] Process kworker/4:2H (pid: 847, stack limit = 0x000000006e538c8b) > … > > [ 193.010729] Call trace: > … > > [ 193.010742] f_midi_transmit+0x90/0x5d8 [usb_f_midi] > The lock it asks for > > > [ 193.010745] f_midi_complete+0x11c/0x138 [usb_f_midi] > > [ 193.010754] usb_gadget_giveback_request+0x10/0x18 > > [ 193.010758] __usbhsg_queue_pop+0x3c/0x58 > > [ 193.010760] usbhsg_queue_done+0x44/0x60 > > [ 193.010763] usbhsf_pkt_handler+0x80/0x120 > > [ 193.010766] usbhs_pkt_start+0x10/0x18 > > [ 193.010768] usbhsg_queue_push.isra.0+0x44/0x50 > > [ 193.010771] usbhsg_ep_queue+0x2c/0x40 > > [ 193.010773] usb_ep_queue+0x24/0x40 > > [ 193.010776] f_midi_transmit+0x238/0x5d8 [usb_f_midi] > The lock it already acquired. > > > [ 193.010779] f_midi_in_work+0x10/0x18 [usb_f_midi] > > [ 193.010786] process_one_work+0x1e8/0x340 > > [ 193.010788] worker_thread+0x40/0x458 > > [ 193.010792] kthread+0x16c/0x170 > > [ 193.010797] ret_from_fork+0x10/0x1c > … > > > > Let me know if there is anything more useful here or if there's any > > other information I can provide. > > Looking at v6.13, the code flow is still the same. I don't see how !RT > is not affected by this. The tasklet to workqueue change didn't change > the logic here, it only changed the API and the context but the > recursion remains. > > So a simple "tasklet_hi_schedule(&midi->tasklet);" instead of > "f_midi_transmit(midi)" in f_midi_complete() might do the trick. > > > Thanks > > Sebastian
