Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 592908 - Memory leak when nfs shares are mounted with option "nolock"
Memory leak when nfs shares are mounted with option "nolock"
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: ---
Assigned To: Jeff Layton
yanfu,wang
:
Depends On:
Blocks: 973975 1032944
  Show dependency treegraph
 
Reported: 2010-05-17 06:43 EDT by Sachin Prabhu
Modified: 2018-11-14 14:32 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 973975 1032944 (view as bug list)
Environment:
Last Closed: 2011-01-13 16:32:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0017 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.6 kernel security and bug fix update 2011-01-13 05:37:42 EST

  None (edit)
Description Sachin Prabhu 2010-05-17 06:43:59 EDT
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@netapp.com>
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@netapp.com>
    Acked-by: NeilBrown <neilb@suse.de>


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.
Comment 1 Jeff Layton 2010-05-17 07:02:45 EDT
Looks pretty straightforward.
Comment 3 RHEL Product and Program Management 2010-06-08 08:39:58 EDT
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.
Comment 5 Jarod Wilson 2010-07-12 11:46:35 EDT
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.
Comment 8 yanfu,wang 2010-10-19 01:45:49 EDT
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
Comment 10 errata-xmlrpc 2011-01-13 16:32:08 EST
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

Note You need to log in before you can comment on or make changes to this bug.