Memory leak problem with JFFS2

[Frederic Giasson]

Hi David,

I took some time to track down the memory leak that happens after umount.
First I compiled JFFS2 as a module and loaded/unloaded it doing a
mount/umount in between.  No BUG occured, meaning that no slab object is
still allocated when I unload the module.  Then I investigated around the
kmalloc/kfree, but I found nothing.  I put traces and counters each time a
kmalloc / kfree was called, and the number of kmalloc and kfree is balanced.
Therefore, I can conclude than the memory leak is not an allocated object
still allocated at umount time and is not a kmalloc without kfree neither.
Do you have any other idea about it?  This is not very likely to be the
mount / umount mechanism that could cause the leak, I tried mounting and
unmounting NFS and the memory usage before and after does not change. 

Between, we still don't know why doing a sync after an "rm" command triggers
the garbage collector.  Do you have any other clue about it?

Frédéric Giasson


|-----Original Message-----
|From: David Woodhouse [mailto:dwmw2 at infradead.org]
|Sent: Wednesday, July 10, 2002 5:48 AM
|To: Frederic Giasson
|Cc: linux-mtd at lists.infradead.org
|Subject: Re: Memory leak problem with JFFS2 
|
|
|
|fgiasson at mediatrix.com said:
|>  So to confirm that the leak comes from the fact of doing repeated
|> mount/umount, I setup a third test which is exactly like the first
|> test, except that I removed mount and umount commands. That time free
|> memory usage remained constant, which make me think that the leak is
|> probably related to memory incorrectly freed at umount time.
|> Nevertheless, the third test also hanged, after 170 loops, at copy
|> command.	
|
|Strange. Most JFFS2 memory allocations are done through 
|dedicated slabs, 
|rather than with kmalloc(). Can you reproduce this with JFFS2 
|as a module, 
|unloading and reloading the module each time the file system 
|is unmounted? 
|That should cause a BUG() if any slab objects are still 
|allocated when you 
|try to unload the module. 
|
|If it's a kmalloc(). there are few enough of them that it should be 
|possible to track it down.
|
|>  That time free memory usage remained constant, which make me think
|> that the leak is probably related to memory incorrectly freed at
|> umount time.  Nevertheless, the third test also hanged, after 170
|> loops, at copy command.		 
|
|That shouldn't ever happen. Where was it spending the time? 
|(SysRq-P is 
|your friend). If you can reproduce with debugging and show what it's 
|actually _doing_ during this time, that would be useful.
|
|>  Between, note that the sync command sprinkled in the test loops are
|> there to speed up the process.  In fact, I observed that doing a sync
|> after a file erasure triggers the gc and wait for it to complete its
|> task, so when I write data to JFFS2 after it does not need to garbage
|> collect in the mean time.  This makes write times to JFFS2 much more
|> deterministic. 
|
|Interesting. I'm not entirely convinced I know why that 
|happens. sync() 
|shouldn't really do anything at all.
|
|>  I am using linux kernel 2.4.19 pre 7, and JFFS2 code from CVS as per
|> May 14th, 2002.  By the way, does anybody can tell me if 
|there is some
|> sorts of branches or labels in JFFS2 CVS, other that time stamps?  Is
|> there a label per linux release, for instance? 
|
|There is occasionally a branch made for really experimental 
|code, like when 
|we started on NAND support. At the moment there aren't any 
|such branches. 
|All we have is the development on the trunk, and the 
|jffs2-2_4-branch which 
|contains the same code as is in Marcelo's 2.4.19-rc2. 
|
|For anyone using JFFS2 in production, I would recommend using 
|that version, 
|rather than the trunk code. 
|
|--
|dwmw2
|
|