On Sun, Jun 28, 2009 at 11:37 PM, Oliver Neukum<oliver@xxxxxxxxxx> wrote: > Am Sonntag, 28. Juni 2009 23:09:28 schrieb Alan Stern: >> On Sun, 28 Jun 2009, Oliver Neukum wrote: >> > Hi, >> > >> > looking at devio.c::processcompl in connection with a memleak Markus >> > reported, it seems to me the devio.c::processcompl in the error case >> > fails to free struct async. This is fatal, as proc_reapurb has already >> > removed the struct async from the completed list with reap_as. >> > >> > Am I imagining this? Shall I submit the obvious fix? >> >> You are right. Fix away! > > This is pretty old and fundamental code. How did we overlook this? > there are not so many extensive usbfs users out there.. I got around the leak when trying to stream 21 mbyte/seconds from a USB 2.0 device. I left the transfer on over night and in the morning the notebook was somewhat frozen (I never looked for how long it worked but as I showed you the slabinfo kmalloc allocation jumps up constantly while streaming). The buffer size of 32k was enough for the entire transfer, although I think virtualized guests might have a problem with such small buffers. The windows driver allocates around 190k per URB while USBFS won't accept more than 32k. thanks for having a closer look at it, as I'm still working on the userland side :-) Markus -- 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
