Re: 3.10.4: kmemleak in usb_get_bos_descriptor()?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/23/2013 05:07 PM, Alan Stern wrote:
On Fri, 23 Aug 2013, Xenia Ragiadakou wrote:

Martin is right; the BOS descriptors are leaked in
usb_reset_and_verify_device().  We need to store the old descriptor,
compare it with the new one following the reset, and delete one of them
afterward.  I haven't had time to fix this.
I'll put it in my list of future tasks to give to Xenia. :)

Alan, if you have any other small tasks for OPW interns, please let me
know.

Sarah Sharp
Hi,

I will try to fix this leak :)
First i would like to ensure that i understood the problem so ...

If i understood well the usb device's bos descriptor is allocated
everytime hub_port_init()
is called without never being freed, right?
Yes.

I do not understand why to compare the old bos with the new one, and not
just release the old one
or store the new in the memory allocated for the old one.
usb_reset_and_verify_device() checks to see if the descriptors changed
when the device was reset.  (If they did then we need to re-enumerate
the device.)  It calls descriptors_changed() to do this checking.

Originally there were no BOS descriptors, so of course the routine
didn't try to compare them.  But now that they exist, we need to
compare the old and new descriptor values, same as for the device and
config descriptors.  And of course we need to deallocate one of the BOS
descriptors, instead of leaking it.

Alan Stern


Thanks for the clarification.
I will send a patch as RFC because i am not quite familiar and because i have a problem to run kmemleak effectively (i can only scan for a few seconds, although i have set all necessary kmemleak configuration, i have not figured out why yet).

I perform the deallocation outside the descriptors_changed(). That leads to code duplication, but if i perform it inside, the function will do something that is not expected to do, right?

Also, another thing is that even if the device descriptors have not change (and thus the bcdUSB), there is still the possibility one of the two bos descriptors to be null while the other one is not, either due to a kmalloc() failure or in case the usb device version is in the range [0x201, 0x210) where bos descriptors are optional and if new firmware is downloaded in the device may has as result to add or remove the bos descriptor support. Am i thinking correctly here?

regards,
ksenia
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux