Bug 1305428 - [Fuse: ] crash while --attribute-timeout and -entry-timeout are set to 0
[Fuse: ] crash while --attribute-timeout and -entry-timeout are set to 0
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: fuse (Show other bugs)
3.7.7
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ashish Pandey
:
Depends On: 1299410
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-08 03:27 EST by Ashish Pandey
Modified: 2016-04-19 03:26 EDT (History)
1 user (show)

See Also:
Fixed In Version: glusterfs-3.7.9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1299410
Environment:
Last Closed: 2016-04-19 03:26:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ashish Pandey 2016-02-08 03:27:05 EST
+++ This bug was initially created as a clone of Bug #1299410 +++

Description of problem:

Core was generated by `glusterfs --attribute-timeout=0 --entry-timeout=0 --volfile-id=/patchy --volfil'.


Version-Release number of selected component (if applicable):


How reproducible:
1/1

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
It should not crash.

Additional info:

--- Additional comment from Vijay Bellur on 2016-01-18 05:34:46 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Check priv and active_vol variable for NULL       before calling inode_table_dump) posted (#1) for review on master by Ashish Pandey (aspandey@redhat.com)

--- Additional comment from Vijay Bellur on 2016-01-22 01:09:57 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#2) for review on master by Ashish Pandey (aspandey@redhat.com)

--- Additional comment from Ashish Pandey on 2016-01-22 01:13:55 EST ---

This bug is reproducible while running the ec-notify.t test in loop. 

Immediately after starting a disperse volume (2+1) kill one brick and just after that try to mount it through fuse. This lead to crash.

--- Additional comment from Vijay Bellur on 2016-01-22 03:45:40 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#3) for review on master by Raghavendra G (rgowdapp@redhat.com)

--- Additional comment from Vijay Bellur on 2016-01-22 03:46:50 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#4) for review on master by Raghavendra G (rgowdapp@redhat.com)

--- Additional comment from Vijay Bellur on 2016-01-22 03:48:09 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#5) for review on master by Raghavendra G (rgowdapp@redhat.com)

--- Additional comment from Vijay Bellur on 2016-01-22 03:50:46 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#6) for review on master by Raghavendra G (rgowdapp@redhat.com)

--- Additional comment from Vijay Bellur on 2016-01-27 00:33:12 EST ---

REVIEW: http://review.gluster.org/13253 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#7) for review on master by Ashish Pandey (aspandey@redhat.com)

--- Additional comment from Vijay Bellur on 2016-02-08 03:24:48 EST ---

COMMIT: http://review.gluster.org/13253 committed in master by Raghavendra G (rgowdapp@redhat.com) 
------
commit 8ad742de98da284539b8ae772e0990294412da01
Author: Ashish Pandey <aspandey@redhat.com>
Date:   Mon Jan 18 15:57:41 2016 +0530

    Fuse: Add a check for NULL in fuse_itable_dump
    
    Problem: Immediately after starting a disperse volume (2+1)
    kill one brick and just after that try to mount it
    through fuse. This lead to crash.
    
    Our test scripts use process statedumps to determine various things
    like whether they are up, connected to bricks etc. It takes some time
    for an active_subvol to be be associated with fuse even after mount
    process is daemonized. This time is normally a function of completion
    of handshake with bricks. So, if we try to take statedump in this time
    window, fuse wouldn't have an active_subvol associated with it leading
    to this crash.
    
    This happened while executing ec-notify.t, which contains above steps.
    
    Solution: Check priv and  priv->active_subvol for NULL before
    inode_table_dump. If priv->active_subvol is null its perfectly fine to
    skip dumping of inode table as inode table is associated with an
    active_subvol. A Null active_subvol indicates initialization in
    progress and fuse wouldn't even have started reading requests from
    /dev/fuse and hence there wouldn't be any inodes or file system
    activity.
    
    Change-Id: I323a154789edf8182dbd1ac5ec7ae07bf59b2060
    BUG: 1299410
    Signed-off-by: Ashish Pandey <aspandey@redhat.com>
    Reviewed-on: http://review.gluster.org/13253
    Smoke: Gluster Build System <jenkins@build.gluster.com>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Comment 1 Vijay Bellur 2016-02-08 03:57:37 EST
REVIEW: http://review.gluster.org/13396 (Fuse: Add a check for NULL in fuse_itable_dump) posted (#1) for review on release-3.7 by Ashish Pandey (aspandey@redhat.com)
Comment 2 Vijay Bellur 2016-02-09 00:25:37 EST
COMMIT: http://review.gluster.org/13396 committed in release-3.7 by Raghavendra G (rgowdapp@redhat.com) 
------
commit 1bfa7d3894a5217a425ac01ab5f952bab56afa2d
Author: Ashish Pandey <aspandey@redhat.com>
Date:   Mon Jan 18 15:57:41 2016 +0530

    Fuse: Add a check for NULL in fuse_itable_dump
    
    Problem: Immediately after starting a disperse volume (2+1)
    kill one brick and just after that try to mount it
    through fuse. This lead to crash.
    
    Our test scripts use process statedumps to determine various things
    like whether they are up, connected to bricks etc. It takes some time
    for an active_subvol to be be associated with fuse even after mount
    process is daemonized. This time is normally a function of completion
    of handshake with bricks. So, if we try to take statedump in this time
    window, fuse wouldn't have an active_subvol associated with it leading
    to this crash.
    
    This happened while executing ec-notify.t, which contains above steps.
    
    Solution: Check priv and  priv->active_subvol for NULL before
    inode_table_dump. If priv->active_subvol is null its perfectly fine to
    skip dumping of inode table as inode table is associated with an
    active_subvol. A Null active_subvol indicates initialization in
    progress and fuse wouldn't even have started reading requests from
    /dev/fuse and hence there wouldn't be any inodes or file system
    activity.
    
    Change-Id: I323a154789edf8182dbd1ac5ec7ae07bf59b2060
    BUG: 1305428
    Signed-off-by: Ashish Pandey <aspandey@redhat.com>
    Reviewed-on: http://review.gluster.org/13253
    Smoke: Gluster Build System <jenkins@build.gluster.com>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
    Signed-off-by: Ashish Pandey <aspandey@redhat.com>
    Reviewed-on: http://review.gluster.org/13396
    Reviewed-by: Xavier Hernandez <xhernandez@datalab.es>
Comment 3 Mike McCune 2016-03-28 18:17:27 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 4 Kaushal 2016-04-19 03:26:12 EDT
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-3.7.9, please open a new bug report.

glusterfs-3.7.9 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] https://www.gluster.org/pipermail/gluster-users/2016-March/025922.html
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

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