[Bugs] [Bug 1401032] OOM kill of nfs-ganesha on one node while fs-sanity test suite is executed.

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1401032



--- Comment #2 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: http://review.gluster.org/16016 committed in release-3.7 by Raghavendra
G (rgowdapp at redhat.com) 
------
commit ec3322bc932d2277873dc337b19c88381df78106
Author: Jiffin Tony Thottan <jthottan at redhat.com>
Date:   Mon Nov 21 18:08:14 2016 +0530

    dht/rename : Incase of failure remove linkto file properly

    Generally linkto file is created using root user. Consider following
    case, a user is trying to rename a file which he is not permitted.
    So the rename fails with EACESS and when rename tries to cleanup the
    linkto file, it fails.

    The above issue happens when rename/00.t test executed on nfs-ganesha
    clients :
    Steps executed in script
    * create a file "abc" using root
    * rename the file "abc" to "xyz" using a non root user, it fails with
EACESS
    * delete "abc"
    * create directory "abc" using root
    * again try ot rename "abc" to "xyz" using non root user, test hungs here
    which slowly leds to OOM kill of ganesha process

    RCA put forwarded by Du for OOM kill of ganesha
    Note that when we hit this bug, we've a scenario of a dentry being
    present as:
        * a linkto file on one subvol
        * a directory on rest of subvols

    When a lookup happens on the dentry in such a scenario, the control flow
    goes into an infinite loop of:

        dht_lookup_everywhere
        dht_lookup_everywhere_cbk
        dht_lookup_unlink_cbk
        dht_lookup_everywhere_done
        dht_lookup_directory (as local->dir_count > 0)
        dht_lookup_dir_cbk (sets to local->need_selfheal = 1 as the entry is a
linkto file on one of the subvol)
        dht_lookup_everywhere (as need_selfheal = 1).

    This infinite loop can cause increased consumption of memory due to:
    1) dht_lookup_directory assigns a new layout to local->layout
unconditionally
    2)  Most of the functions in this loop do a stack_wind of various fops.

    This results in growing of call stack (note that call-stack is destroyed
only after lookup response is
    received by fuse - which never happens in this case)

    Thanks Du for root causing the oom kill and Sushant for suggesting the fix

    Upstream reference :
    >Change-Id: I1e16bc14aa685542afbd21188426ecb61fd2689d
    >BUG: 1397052
    >Signed-off-by: Jiffin Tony Thottan <jthottan at redhat.com>
    >Reviewed-on: http://review.gluster.org/15894
    >NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    >CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    >Smoke: Gluster Build System <jenkins at build.gluster.org>
    >Reviewed-by: Raghavendra G <rgowdapp at redhat.com>
    >(cherry picked from commit 57d59f4be205ae0c7888758366dc0049bdcfe449)

    Change-Id: I1e16bc14aa685542afbd21188426ecb61fd2689d
    BUG: 1401032
    Signed-off-by: Jiffin Tony Thottan <jthottan at redhat.com>
    Reviewed-on: http://review.gluster.org/16016
    Smoke: Gluster Build System <jenkins at build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    Reviewed-by: Raghavendra G <rgowdapp at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dee85QqjNN&a=cc_unsubscribe