[Bugs] [Bug 1396418] [md-cache]: All bricks crashed while performing symlink and rename from client at the same time

[bugzilla at redhat.com]

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



--- Comment #4 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: http://review.gluster.org/15878 committed in release-3.8 by Rajesh
Joseph (rjoseph at redhat.com) 
------
commit 0930424c82721355a3869a4837ac4cb9938065a6
Author: Poornima G <pgurusid at redhat.com>
Date:   Fri Nov 11 12:08:57 2016 +0530

    marker: Fix inode value in loc, in setxattr fop

    Backport of http://review.gluster.org/15826

    On recieving a rename fop, marker_rename() stores the,
    oldloc and newloc in its 'local' struct, once the rename
    is done, the xtime marker(last updated time) is set on
    the file, but sending a setxattr fop. When upcall
    receives the setxattr fop, the loc->inode is NULL and
    it crashes. The loc->inode can be NULL only in one valid
    case, i.e. in rename case where the inode of new loc
    can be NULL. Hence, marker should have filled the inode
    of the new_loc before issuing a setxattr.

    > Reviewed-on: http://review.gluster.org/15826
    > NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    > CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    > Reviewed-by: Kotresh HR <khiremat at redhat.com>
    > Smoke: Gluster Build System <jenkins at build.gluster.org>
    > Reviewed-by: Rajesh Joseph <rjoseph at redhat.com>
    (cherry picked from commit 46e5466850311ee69e6ae9a11c2bba2aabadd5de)

    Change-Id: Id638f678c3daaf4a5c29b970b58929d377ae8977
    BUG: 1396418
    Signed-off-by: Poornima G <pgurusid at redhat.com>
    Reviewed-on: http://review.gluster.org/15878
    Reviewed-by: Rajesh Joseph <rjoseph at redhat.com>
    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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.