> -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > owner@xxxxxxxxxxxxxxx] On Behalf Of Sarah Sharp > Sent: Friday, August 05, 2011 2:45 AM > To: Xu, Andiry > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: [RFC 1/3] xhci: Fix memory leak during failed enqueue. > > When the isochronous transfer support was introduced, and the xHCI > driver > switched to using urb->hcpriv to store an "urb_priv" pointer, a couple > of > memory leaks were introduced into the URB enqueue function in its error > handling paths. > > xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing > the control endpoint's max packet size fails or the bulk endpoint is in > the middle of allocating or deallocating streams. > > xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint > types' enqueue functions fail. Instead, it expects those functions to > free urb_priv if an error occurs. However, the bulk, control, and > interrupt enqueue functions do not free urb_priv if the endpoint ring > is > NULL. It will, however, get freed if prepare_transfer() fails in those > enqueue functions. > > Several of the error paths in the isochronous endpoint enqueue function > also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free > urb_priv > if prepare_ring() indicates there is not enough room for all the > isochronous TDs in this URB. If individual isochronous TDs fail to be > queued (perhaps due to an endpoint state change), urb_priv is also > leaked. > > This argues that the freeing of urb_priv should be done in the function > that allocated it, xhci_urb_enqueue. > > This patch looks rather ugly, but refactoring the code will have to > wait > because this patch needs to be backported to stable kernels. > > This patch should be backported to kernels as old as 2.6.36. > > Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> > Cc: Andiry Xu <andiry.xu@xxxxxxx> This looks OK to me. Thanks, Andiry -- 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
