Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit da8bfb09 authored by Alan Stern's avatar Alan Stern Committed by Greg Kroah-Hartman
Browse files

USB documentation: explain lifetime rules for unlinking URBs 



This patch (as1534c) updates the documentation for usb_unlink_urb and
related functions.  It explains that the caller must prevent the URB
being unlinked from getting deallocated while the unlink is taking
place.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent bcf39853

Documentation/usb/URB.txt

+22 −0
Original line number Diff line number Diff line
@@ -168,6 +168,28 @@ that if the completion handler or anyone else tries to resubmit it 
they will get a -EPERM error.  Thus you can be sure that when

usb_kill_urb() returns, the URB is totally idle.



There is a lifetime issue to consider.  An URB may complete at any

time, and the completion handler may free the URB.  If this happens

while usb_unlink_urb or usb_kill_urb is running, it will cause a

memory-access violation.  The driver is responsible for avoiding this,

which often means some sort of lock will be needed to prevent the URB

from being deallocated while it is still in use.



On the other hand, since usb_unlink_urb may end up calling the

completion handler, the handler must not take any lock that is held

when usb_unlink_urb is invoked.  The general solution to this problem

is to increment the URB's reference count while holding the lock, then

drop the lock and call usb_unlink_urb or usb_kill_urb, and then

decrement the URB's reference count.  You increment the reference

count by calling



	struct urb *usb_get_urb(struct urb *urb)



(ignore the return value; it is the same as the argument) and

decrement the reference count by calling usb_free_urb.  Of course,

none of this is necessary if there's no danger of the URB being freed

by the completion handler.





1.7. What about the completion handler?

drivers/usb/core/urb.c

+12 −0
Original line number Diff line number Diff line
@@ -539,6 +539,10 @@ EXPORT_SYMBOL_GPL(usb_submit_urb); 
 * never submitted, or it was unlinked before, or the hardware is already

 * finished with it), even if the completion handler has not yet run.

 *

 * The URB must not be deallocated while this routine is running.  In

 * particular, when a driver calls this routine, it must insure that the

 * completion handler cannot deallocate the URB.

 *

 * Unlinking and Endpoint Queues:

 *

 * [The behaviors and guarantees described below do not apply to virtual
@@ -603,6 +607,10 @@ EXPORT_SYMBOL_GPL(usb_unlink_urb); 
 * with error -EPERM.  Thus even if the URB's completion handler always

 * tries to resubmit, it will not succeed and the URB will become idle.

 *

 * The URB must not be deallocated while this routine is running.  In

 * particular, when a driver calls this routine, it must insure that the

 * completion handler cannot deallocate the URB.

 *

 * This routine may not be used in an interrupt context (such as a bottom

 * half or a completion handler), or when holding a spinlock, or in other

 * situations where the caller can't schedule().
@@ -640,6 +648,10 @@ EXPORT_SYMBOL_GPL(usb_kill_urb); 
 * with error -EPERM.  Thus even if the URB's completion handler always

 * tries to resubmit, it will not succeed and the URB will become idle.

 *

 * The URB must not be deallocated while this routine is running.  In

 * particular, when a driver calls this routine, it must insure that the

 * completion handler cannot deallocate the URB.

 *

 * This routine may not be used in an interrupt context (such as a bottom

 * half or a completion handler), or when holding a spinlock, or in other

 * situations where the caller can't schedule().