> > ------------------------------------------------------------------------
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:1115:usb_parse_configuration: ERROR: did not free config on error path
> >
> > Not sure: looks like you'll just overwrite it on the second pass:
> >
> > config->interface = (struct usb_interface *)
> > kmalloc(config->bNumInterfaces *
> > sizeof(struct usb_interface), GFP_KERNEL);
>
> Second pass?
Good question ;-) I (unclearly) meant that if you reran this routine
after it failed with an error in order to try to make more progress, it
will overwrite these pointers losing storage. A common source of false
positives for this check is kernel routines that, on a retry attempt,
only allocate memory for null pointers.
> FWIW, usb_destroy_configuration does free this.
>
> This is assuming that whoever calls usb_get_configuration (which
> eventually ends up calling usb_parse_configuration) handles the error
> code correctly and calls usb_destroy_configuration, which it doesn't.
Ah. Thanks.
> > UNSURE, but it looks like all these interface allocations will be lost.
> > If it fails, they just get overwritten.
>
> I don't understand what you mean by "overwritten"?
Same thing as above.
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:1038:usb_parse_interface: ERROR: did not free interface on error path
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:1023:usb_parse_interface: ERROR: did not free interface on error path
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:990:usb_parse_interface: ERROR: did not free interface on error path
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:956:usb_parse_interface: ERROR: did not free interface on error path
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:1057:usb_parse_interface: ERROR: did not free interface on error path
> > /u2/engler/ic/linux-2.3.99/drivers/usb/usb.c:1046:usb_parse_interface: ERROR: did not free interface on error path
>
> Why did it show many of those multiple times?
It gives a message for each unique return-with-error path that has
unfreed storage.
> These fall under the same category as the first.
Great; thanks for letting us know!
Dawson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:26 EST