[Bugs] [Bug 1396414] [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=1396414



--- Comment #4 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: http://review.gluster.org/15877 committed in release-3.9 by Rajesh
Joseph (rjoseph at redhat.com) 
------
commit f5192cffe716d4db6de39a3e132d16c918d3846e
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: 1396414
    Signed-off-by: Poornima G <pgurusid at redhat.com>
    Reviewed-on: http://review.gluster.org/15877
    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.