[Bug 1405] New: Memory leak in VFS?

[Martin J. Bligh]

http://bugme.osdl.org/show_bug.cgi?id=1405

           Summary: Memory leak in VFS?
    Kernel Version: 2.6.0-test8-bk1
            Status: NEW
          Severity: normal
             Owner: akpm@xxxxxxxxx
         Submitter: bwindle-kbt@xxxxxxxx


Distribution: Debian Testing
Hardware Environment: SMP, Preempt, i386, SCSI
Software Environment: 
Linux dual266 2.6.0-test8-bk1 #6 SMP Tue Oct 21 11:34:44 EDT 2003 i686 GNU/Linux

Gnu C                  3.3.2
Gnu make               3.80
util-linux             2.12
mount                  2.12
module-init-tools      implemented
e2fsprogs              1.35-WIP
nfs-utils              1.0.5
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Procps                 3.1.12
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.0

Problem Description:
There appears to be a memory leak in the VFS code.  Nikita Danilov
<Nikita@xxxxxxxxxxx> posted to the LKML, and I am able to reproduce the
situation. Running fsstress (file system stress tools from XFS ported by Andi
Kleen <ak@xxxxxxx>) on an ext3 filesystem as 

./fsstress -d . -f sync=0 -n 1000000000 -p 111 -v

The kernel begins to use lots of memory in ext3_inode_cache and dentry_cache.
Nikita was able to do this on ext2, and reiser, and I can reproduce it on ext3.
The memory will not release under VM pressure, but does appear to release some
of it if you erase the files created by the fsstress tool. With basically
nothing running, /proc/meminfo is reporting over 50megs Active. The kernel will
not release this memory, despite userspace trying to alloc memory (the alloc'ing
process will instead be killed).  The filesystem is mounted with the default
options (ordered data mode)

There was a change to fs/dcache.c in 2.6.0-test6 that may be responsible.

Steps to reproduce:
run ./fsstress -d . -f sync=0 -n 1000000000 -p 111 -v for a while (an hour or so).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/