A nfs client which repeatedly mounts shares using the option nolock experiences a memory leak. The slab objects rpc_inode_cache and size-4096 steadily increase. This issue was also reported at https://bugzilla.novell.com/show_bug.cgi?id=336253#c24 This was also reported upstream http://kerneltrap.org/mailarchive/linux-nfs/2007/12/11/487982/thread This is fixed in 2.6.24 in the following commit commit 5cef338b30c110daf547fb13d99f0c77f2a79fbc Author: Trond Myklebust <Trond.Myklebust> Date: Tue Dec 11 22:01:56 2007 -0500 NFSv2/v3: Fix a memory leak when using -onolock Neil Brown said: > Hi Trond, > > We found that a machine which made moderately heavy use of > 'automount' was leaking some nfs data structures - particularly the > 4K allocated by rpc_alloc_iostats. > It turns out that this only happens with filesystems with -onolock > set. > The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't > set server->destroy, so when the filesystem is unmounted, the > ->client_acl is not shutdown, and so several resources are still > held. Multiple mount/umount cycles will slowly eat away memory > several pages at a time. Signed-off-by: Trond Myklebust <Trond.Myklebust> Acked-by: NeilBrown <neilb> Reproducer: We need 2 terminals 1) On first terminal, keep a tab on the slab objects using the command watch "egrep 'rpc_inode_cache|size-4096'" /proc/slabinfo 2) On the second run a loop of mounts and umounts for i in {1..10000}; do mount vm23:/exports -o nolock /mnt/m1/; umount /mnt/m1; done You will see steadily increasing numbers of allocated rpc_inode_cache and size-4096 slab objects.
Looks pretty straightforward.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-206.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
reproduced on rhel5.5: # uname -a Linux amd-ma78gm-02.lab.bos.redhat.com 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux # egrep 'rpc_inode_cache|size-4096' /proc/slabinfo rpc_inode_cache 6 10 768 5 1 : tunables 54 27 8 : slabdata 2 2 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 160 160 4096 1 1 : tunables 24 12 8 : slabdata 160 160 0 # egrep 'rpc_inode_cache|size-4096' /proc/slabinfo rpc_inode_cache 12435 12435 768 5 1 : tunables 54 27 8 : slabdata 2487 2487 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 6435 6435 4096 1 1 : tunables 24 12 8 : slabdata 6435 6435 0 ... # egrep 'rpc_inode_cache|size-4096' /proc/slabinfo rpc_inode_cache 37200 37210 768 5 1 : tunables 54 27 8 : slabdata 7442 7442 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 18779 18779 4096 1 1 : tunables 24 12 8 : slabdata 18779 18779 0 verified on RHEL5.6-Server-20101014.0 on i386 and x86_64, now the slab objects rpc_inode_cache and size-4096 haven't been steadily increased. # uname -a Linux dell-t5500-01.lab.bos.redhat.com 2.6.18-227.el5 #1 SMP Tue Oct 12 18:50:50 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux # egrep 'rpc_inode_cache|size-4096' /proc/slabinfo rpc_inode_cache 13 15 768 5 1 : tunables 54 27 8 : slabdata 3 3 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 409 410 4096 1 1 : tunables 24 12 8 : slabdata 409 410 0
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html