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?
Ciao,
Duncan.
More information about the Usbatm
mailing list