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

Roman Kagan rkagan at mail.ru
Sat Feb 12 10:19:49 EST 2005

On Sat, Feb 12, 2005 at 03:50:26PM +0100, matthieu castet wrote:
> >>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).


More information about the Usbatm mailing list