Bug 1557876 - Fuse mount crashed with only one VM running with its image on that volume
Summary: Fuse mount crashed with only one VM running with its image on that volume
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: sharding
Version: mainline
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Pranith Kumar K
QA Contact: bugs@gluster.org
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-19 07:10 UTC by Pranith Kumar K
Modified: 2018-06-20 18:02 UTC (History)
9 users (show)

Fixed In Version: glusterfs-v4.1.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1556895
Environment:
Last Closed: 2018-06-20 18:02:26 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Comment 1 Pranith Kumar K 2018-03-19 07:11:15 UTC
    Problem:
    shard_post_lookup_fsync_handler() goes over the list of
    inode-ctx that need to be fsynced and in cbk it removes each of
    the inode-ctx from the list. When the first such member is removed
    from the list it tries to modifies list head's memory with the
    latest next/prev and when this happens, there is no guarantee
    that the stack memory is valid.
    
    Fix:
    Do list_del_init() in the loop before winding fsync.

Comment 2 Pranith Kumar K 2018-03-19 07:18:52 UTC
https://review.gluster.org/#/c/19737/1

Comment 3 Worker Ant 2018-03-19 07:20:46 UTC
REVIEW: https://review.gluster.org/19737 (features/shard: Do list_del_init() while list memory is valid) posted (#1) for review on master by Pranith Kumar Karampuri

Comment 4 Worker Ant 2018-03-20 08:58:04 UTC
COMMIT: https://review.gluster.org/19737 committed in master by "Pranith Kumar Karampuri" <pkarampu> with a commit message- features/shard: Do list_del_init() while list memory is valid

Problem:
shard_post_lookup_fsync_handler() goes over the list of inode-ctx that need to
be fsynced and in cbk it removes each of the inode-ctx from the list. When the
first member of list is removed it tries to modifies list head's memory with
the latest next/prev and when this happens, there is no guarantee that the
list-head which is from stack memory of shard_post_lookup_fsync_handler() is
valid.

Fix:
Do list_del_init() in the loop before winding fsync.

BUG: 1557876
Change-Id: If429d3634219e1a435bd0da0ed985c646c59c2ca
Signed-off-by: Pranith Kumar K <pkarampu>

Comment 5 Shyamsundar 2018-06-20 18:02:26 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-v4.1.0, please open a new bug report.

glusterfs-v4.1.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2018-June/000102.html
[2] https://www.gluster.org/pipermail/gluster-users/


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