Possible recursive locking detected

[jaapcrezee]

Hi all,

I just merged in a new USBProxy & BBB kernel (3.14.35 => https://github.com/beagleboard/linux) and saw:

[ 13.972344] =============================================
[ 13.978010] [ INFO: possible recursive locking detected ]
[ 13.983681] 3.14.35-zupr+ #2 Not tainted
[ 13.987795] ---------------------------------------------
[ 13.993461] usb-mitm/265 is trying to acquire lock:
13.998580{-.-...}, at: [] ep0_complete+0x18/0xe0 [gadgetfs]
[ 14.007969]
[ 14.007969] but task is already holding lock:
14.014093{-.-...}, at: [] ep0_read+0x20/0x574 [gadgetfs]

Is it a gadgetfs related kernel bug or is it a USBProxy bug? (my binary is called usb-mitm).

See complete dmesg here: http://jcz.nl/usbproxy/dmesg

USBProxy started like:
/zupr/bin/usb-mitm -p1200 -k/tmp/barcode_fifo

Not any hints from USBProxy itself:

Output file /tmp/barcode_fifo opened.
Loading plugins from /usr/local/lib/USBProxy/
vendorId=ffffffff
productId=1200
cleaning up /tmp
removing 0
Made directory /tmp/gadget-6RUeY3 for gadget
Printing Config data
Strings: 3
DeviceProxy: DeviceProxy_LibUSB
HostProxy: HostProxy_GadgetFS
productId: 1200
Vectors: 1
Plugins:
PacketFilter_KeyLogger
PacketFilter_ROT13
Pointer: 1
PacketFilter_KeyLogger::file: 0x1fed138
searching in [/tmp/gadget-6RUeY3]
Starting setup writer thread (237) for EP00.
Starting setup reader thread (236) for EP00.
Opened EP81
Starting writer thread (239) for EP81.
Starting reader thread (238) for EP81.

Around 'Opened EP81' there is some waiting time.
After the last line about starting the reader thread everything just works, usb data from pid 1200 is relayed.
Anybody any idea?

Regards,

Jaap Crezee

[jaapcrezee]

Hmmm, probably never mind. I did not recognize the behaviour: last time I forgot to (re)apply the inode.c patch the device just hanged. When using a kernel with a lot of debugging prints it no longer hangs here, but starts telling whats wrong.

I probably merged out the inode.c patch when resolving other merge conflicts. Sorry.

[dominicgs]

No problem. So I can close this issue?

[jaapcrezee]

Well, I was thinking: can we try to fix this in userspace instead of patching the gadgetfs driver? If you are sure we really cannot, you can close it I guess. Otherwise we (or just maybe me ;)) can invest some more time in it.

[dominicgs]

I'm fairly confident that this is a gadgetfs bug which is unlikely to ever be fixed, but I'd be very happy if you found a method for us to work around it in USBProxy instead of patching the kernel.

I think the real solution here is to stop using gadgetfs (it was broken in 3.19 anyway - https://lkml.org/lkml/2015/3/2/59) and use one of the other methods that has come along since. The thing that I want to do the least is write our own kernel module, because that's likely to cause us issues in the future.