speedtch usbatm.h,1.4,1.5 usbatm2.c,1.13,1.14

Duncan Sands baldrick at free.fr
Sat Feb 12 11:42:53 EST 2005

> > >>If it doesn't go in, I think we at least should remove that bogus kfree 
> > >>call
> > >>in udsl_destroy_instance: a memleak is better than a probability of a
> > >>crash.
> > >
> > >which bogus kfree do you mean?  I see a kfree in udsl_destroy_instance,
> > >but it looks fine to me...
> > 
> > the kfree is done on data which is statically initialized by the driver, 
> > so the kfree is is bogus.
> Not exactly: kfree is done on udsl_instance_data living within the
> kmalloced speedtch_instance_data, which isn't kfreed at all in 2.6.10
> speedtch.  So I suspect removing it would just leave a memleak.
> > But even if we remove the kfree, it won't solve the problem, since we 
> > can unload the driver and erase the instance data(loading an other 
> speedtch in 2.6.10 doesn't erase instance data in disconnect (yes it's a
> bug but not fatal probably).

Hi Roman, I still don't see why it is bogus.  Since the struct
udsl_instance_data is the first element of struct
speedtch_instance_data, a pointer to it is the same thing as a pointer
to the speedtch_instance_data (same memory location).  The kfree will
simply free the speedtch_instance_data, which is what we want, no?



More information about the Usbatm mailing list