On Sat, Aug 31, 2013 at 04:52:47AM +0300, Xenia Ragiadakou wrote:
> On 08/31/2013 04:25 AM, Greg KH wrote:
> > On Sat, Aug 31, 2013 at 04:20:09AM +0300, Xenia Ragiadakou wrote:
> >> In usb_reset_and_verify_device(), hub_port_init() allocates a new bos
> >> descriptor to hold the value read by the device. The new bos descriptor
> >> has to be compared with the old one in order to figure out if device 's
> >> firmware has changed in which case the device has to be reenumerated.
> >> In the original code, none of the two descriptors was deallocated leading
> >> to memory leaks.
> >>
> >> This patch compares the old bos descriptor with the new one to detect change
> >> in firmware and releases the newly allocated bos descriptor to prevent memory
> >> leak.
> >>
> >> Signed-off-by: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
> >> Reported-by: Martin MOKREJS <mmokrejs@xxxxxxxxx>
> >> Tested-by: Martin MOKREJS <mmokrejs@xxxxxxxxx>
> >> Suggested-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> >> ---
> >>
> >> Differences from v2:
> >>
> >> fix incorrect type in assignment ('le16' was assigned to 'unsigned int')
> > I don't want to revert your previous patch, as it's already in my tree,
> > so can you just send a single patch that fixes the issue, giving the
> > proper "Reported-by:" mark for the person who told you about this
> > problem.
> >
> > thanks,.
> >
> > greg k-h
>
> By the way the other incorrect assignments in core/hub.c reported by the
> robot probably is a bug.
> Because bU2DevExitLat is __le16 in struct usb_ss_cap_descriptor and it
> needs to be converted to
> cpu byteorder before assigned to the usb device's lpm parameters.
>
> And since it is reported by robot i suspect it has not been fixed right?
Does sparse complain about it? If you build the kernel with:
make C=1
sparse is run on the files before gcc, and it catches these types of
things. Don't rely on the 0-day buildbot for finding all of the
problems :)
thanks,
greg k-h
--
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
