Hi,
Vincent Pelletier <plr.vincent@xxxxxxxxx> writes:
> On Fri, 24 Nov 2017 16:10:17 +0200, Felipe Balbi <balbi@xxxxxxxxxx>
> wrote:
>> $ gdb vmlinux
>> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
>>
>>
>> what does that give you?
>
> Note: this is a different debugging session, different traceback, but
> same kernel.
>
> $ gdb ./vmlinux
> [...]
> (gdb) target remote /dev/ttyUSB0
> [...]
> (gdb) lx-symbols
> [...]
> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
> 0xf81b50ac is in dwc3_gadget_ep_dequeue (./include/linux/spinlock.h:342).
> 337 raw_spin_lock_nest_lock(spinlock_check(lock), nest_lock); \
> 338 } while (0)
> 339
> 340 static __always_inline void spin_lock_irq(spinlock_t *lock)
> 341 {
> 342 raw_spin_lock_irq(&lock->rlock);
> 343 }
> 344
> 345 #define spin_lock_irqsave(lock, flags) \
> 346 do { \
>
> Which is likely the spin_lock_irqsave call early in the function.
no, it's not. This is because of our call to wait_event_lock_irq() in
dwc3_gadget_ep_dequeue(). That call works fine in all other cases
because dequeue is never called with IRQs disabled, apart from this one
case in f_fs.c :-)
Can you confirm that this helps:
modified drivers/usb/gadget/function/f_fs.c
@@ -1077,15 +1077,11 @@ static int ffs_aio_cancel(struct kiocb *kiocb)
ENTER();
- spin_lock_irq(&epfile->ffs->eps_lock);
-
if (likely(io_data && io_data->ep && io_data->req))
value = usb_ep_dequeue(io_data->ep, io_data->req);
else
value = -EINVAL;
- spin_unlock_irq(&epfile->ffs->eps_lock);
-
return value;
}
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
