On Mon, 7 Mar 2016, David Mosberger wrote: > We are seeing relatively high interrupt latencies due to usb_sg_wait() > calling usb_submit_urb() with interrupts disabled (as a result of its > spin_lock_irq() call). > > As far as I can see, io->lock protects io->status and it's not really > necessary to hold the lock (or disable interrupts) during the > usb_submit_urb() call. It looks like you're right. The important races here are against sg_complete() and usb_sg_cancel(). On the other hand, it looks like io->urb[i]->dev does need to be protected by the spinlock, which it isn't in usb_sg_cancel() or sg_complete(). > Note that the current code doesn't protect against multiple concurrent > calls to usb_sg_wait(): a second caller of usb_sg_wait() could acquire > io->lock when the first caller drops it after calling usb_submit_urb() > and then it could resubmit the same URBs before the first caller gets > a chance to update io->status. This is perhaps an outright bug? There can't be multiple concurrent calls to usb_sg_wait(). Or, if there are, it's already a bug. > Am I missing something? I think you're basically right. Want to submit a patch? Alan Stern -- 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
