alloc/free quesion in ixp4xx driver

alloc/free quesion in ixp4xx driver

[Phil Endecott]

Dear MTD experts,

I have been looking at the MTD ixp4xx driver 
(drivers/mtd/maps/ixp4xx.c), mainly as an example of something that 
uses the ixp4xx expansion bus, and I have a couple of questions.  I 
apologise for being a "newbie" on this subject, I have not written a 
lot of kernel code.

- In ixp4xx_flash_probe(), a struct ixp4xx_flash_info in kalloc()ed.  
Where is it freed?

- In ixp4xx_flash_remove() you have:
       release_resource(info->res);
       kfree(info->res);
   In other places where release_resource() is called I do not see a 
call to kfree().  Is this right?

Most likely, this is all OK and I need to learn more about how these 
functions should be used.  But my thought on seeing this was that the 
kfree() should have been freeing info, not info->res.

I am also uncertain about release_resource() vs. release_mem_region().  
Are they interchangeable?

I have been looking at 2.6.21, but a quick check at 
http://git.infradead.org/?p=mtd-2.6.git;a=blob;f=drivers/mtd/maps/ixp4xx.c;h=7a828e3e6446d7f9254f083d3b02bb2e9e02e9e0;hb=HEAD 
suggests that it is the same in your tree (if I have understood gitweb properly).


Many thanks,

Phil.

P.S. I'm subscribed to the digest, so if you Cc: me in your reply I'll 
see it sooner.

Re: alloc/free quesion in ixp4xx driver

[MikeW]

Phil Endecott <spam_from_linux_mtd <at> chezphil.org> writes:

> 
> Dear MTD experts,
> 
> I have been looking at the MTD ixp4xx driver 
> (drivers/mtd/maps/ixp4xx.c), mainly as an example of something that 
> uses the ixp4xx expansion bus, and I have a couple of questions.  I 
> apologise for being a "newbie" on this subject, I have not written a 
> lot of kernel code.
> 
> - In ixp4xx_flash_probe(), a struct ixp4xx_flash_info in kalloc()ed.  
> Where is it freed?
> 
> - In ixp4xx_flash_remove() you have:
>        release_resource(info->res);
>        kfree(info->res);
>    In other places where release_resource() is called I do not see a 
> call to kfree().  Is this right?
> 
> Most likely, this is all OK and I need to learn more about how these 
> functions should be used.  But my thought on seeing this was that the 
> kfree() should have been freeing info, not info->res.
> 
> I am also uncertain about release_resource() vs. release_mem_region().  
> Are they interchangeable?
> 
> I have been looking at 2.6.21, but a quick check at
> 
>
http://git.infradead.org/?p=mtd-2.6.git;a=blob;
f=drivers/mtd/maps/ixp4xx.c;h=7a828e3e6446d7f9254f083d3b02bb2e9e02e9e0;
hb=HEAD

> suggests that it is the same in your tree (if I have
 understood gitweb properly).
> 
> Many thanks,
> 
> Phil.

Don't think it should kfree(info->res), the release_resource() sorts
out the allocated mem region.

But there should be a kfree(info) somewhere in the driver.

My guess is that you have spotted a typo, and there should be a
kfree(info) next, just outside the if (info->res) block.

The existing code would lead to a memory leak IMHO.
Want to try out the patch !!??

Regards,
MikeW

Re: alloc/free quesion in ixp4xx driver

[Phil Endecott]

MikeW wrote:
> Phil Endecott <spam_from_linux_mtd <at> chezphil.org> writes:
>> - In ixp4xx_flash_probe(), a struct ixp4xx_flash_info in kalloc()ed.  
>> Where is it freed?
>> 
>> - In ixp4xx_flash_remove() you have:
>>        release_resource(info->res);
>>        kfree(info->res);
>>    In other places where release_resource() is called I do not see a 
>> call to kfree().  Is this right?

> Don't think it should kfree(info->res), the release_resource() sorts
> out the allocated mem region.
>
> But there should be a kfree(info) somewhere in the driver.
>
> My guess is that you have spotted a typo, and there should be a
> kfree(info) next, just outside the if (info->res) block.

Similar issues occur in integrator-flash.c, ixp2000.c, physmap.c and physmap_of.c.

I don't have hardware where mtd can be modular; like probably 99% of 
applications it's the root filesystem so it's hard to unload it.  But 
not being able to test it hasn't stopped me from writing a patch, which 
will follow shortly.  I hope that there's someone out there who can 
test it!

Phil.