On Tue, 2 Jul 2013, Ming Lei wrote: > >> I am wondering if holding the lock in usb_hcd_flush_endpoint() can > >> avoid the race completely. Suppose usb_hcd_link_urb_to_ep() in submit > >> path runs on CPU1 just when usb_hcd_flush_endpoint()(called from > >> usb_disable_endpoint()) completes on CPU0, there is no any guarantee > >> that CPU1 can see the up-to-date value of ep->enabled, so the urb might > >> be submitted to HCD successfully. > > > > There is indeed such a guarantee, provided by the spinlock. CPU1 > > acquires urb_list_lock after CPU0 releases it, right? Therefore, all > > stores to memory performed by CPU0 before releasing the lock will > > be visible to CPU1 after it acquires the lock. Therefore CPU1 will see > > that ep->enabled is 0. > > OK, I got it, but looks it is a bit tricky and maybe some comment > is helpful, thanks for your explanation. Adding a comment would be okay. 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
