On Tue, Aug 11, 2020 at 07:39:12PM +0200, Oliver Neukum wrote: > Am Montag, den 10.08.2020, 11:17 -0400 schrieb Alan Stern: > > On Mon, Aug 10, 2020 at 04:35:18PM +0200, Oliver Neukum wrote: > > > > > You mean, the URB could have been anchored already, but another CPU > > could moor it just as this CPU is unachoring it? > > I was worrying about accidental unanchoring of a moored URB, actually. > > > For one thing, I doubt that a single smp_rmb() will provide any real > > protection. For another, it would be best to just avoid races in the > > first place. Can you think of any use case where it makes sense to moor > > an URB just as it is completing (or indeed at any time while it is > > active)? > > No, I am removing it. > > > > I should have said: require drivers that want to unmoor an URB to do so > > either before it is submitted or in (or after) the completion handler. > > In other words, don't moor or unmoor an URB while it is active. How > > about that? > > Entirely reasonable. > > > > What do you think of the API itself? > > > > It looks fine as far as I can tell. But I haven't worked on any drivers > > that use anchors. > > Writing decent documentation for that is actually hard. Any sugestions? In the kerneldoc for usb_moor_urb and usb_unmoor_urb, mention that to avoid races, URBs should be moored or unmoored only when they are not active: before they are submitted, in the completion handler routine, or after the completion handler has run. You'll have to figure out a good way of explaining the advantages of forcing drivers to do their own unmooring. Maybe urb_destroy() should check for URBs that are still moored. Alan Stern
