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
