Re: possible deadlock in f_midi_transmit

[Greg KH]

On Wed, Sep 14, 2022 at 08:49:49PM +0800, Rondreis wrote:
> Hello,
> 
> When fuzzing the Linux kernel driver v6.0-rc4, the following crash was
> triggered.
> 
> HEAD commit: 7e18e42e4b280c85b76967a9106a13ca61c16179
> git tree: upstream
> 
> kernel config: https://pastebin.com/raw/xtrgsXP3
> C reproducer: https://pastebin.com/raw/C1xYEf7Q
> console output: https://pastebin.com/raw/3RLhvQHE
> 
> Basically, in the c reproducer, we use the gadget module to emulate
> attaching a USB device(vendor id: 0x403, product id: 0xff3d, with the
> midi function) and executing some simple sequence of system calls.
> To reproduce this crash, we utilize a third-party library to emulate
> the attaching process: https://github.com/linux-usb-gadgets/libusbgx.
> Just clone this repository, install it, and compile the c
> reproducer with ``` gcc crash.c -lusbgx -lconfig -o crash ``` will do
> the trick.
> 
> I would appreciate it if you have any idea how to solve this bug.
> 
> The crash report is as follows:
> 
> 
> ============================================
> WARNING: possible recursive locking detected
> 6.0.0-rc4+ #20 Not tainted
> --------------------------------------------
> kworker/0:1H/9 is trying to acquire lock:
> ffff888057ed9228 (&midi->transmit_lock){....}-{2:2}, at:
> f_midi_transmit+0x18c/0x1460 drivers/usb/gadget/function/f_midi.c:683
> 
> but task is already holding lock:
> ffff888057ed9228 (&midi->transmit_lock){....}-{2:2}, at:
> f_midi_transmit+0x18c/0x1460 drivers/usb/gadget/function/f_midi.c:683
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>        CPU0
>        ----
>   lock(&midi->transmit_lock);
>   lock(&midi->transmit_lock);
> 
>  *** DEADLOCK ***
> 
>  May be due to missing lock nesting notation

That's a lockdep warning, is this really deadlocking?

If so, I'd recommend asking the midi developers...

thanks,

greg k-h