Bug 1004091 - SMB:smbd crashes while doing volume operations
Summary: SMB:smbd crashes while doing volume operations
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: Unspecified
OS: Unspecified
urgent
unspecified
Target Milestone: ---
Assignee: GlusterFS Bugs list
QA Contact:
URL:
Whiteboard:
Depends On: 1003584 1004519
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-03 22:31 UTC by Anand Avati
Modified: 2015-09-01 23:06 UTC (History)
6 users (show)

Fixed In Version: glusterfs-3.5.0
Doc Type: Bug Fix
Doc Text:
Clone Of: 1003584
Environment:
Last Closed: 2014-04-17 11:47:12 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Comment 1 Anand Avati 2013-09-03 22:46:01 UTC
REVIEW: http://review.gluster.org/5767 (glusterfs, gfapi: fix symbol clash) posted (#1) for review on master by Anand Avati (avati)

Comment 2 Anand Avati 2013-09-05 12:25:26 UTC
COMMIT: http://review.gluster.org/5767 committed in master by Vijay Bellur (vbellur) 
------
commit 4b317e64cafe1e8621a8b24ebb8243931cda264a
Author: Anand Avati <avati>
Date:   Tue Sep 3 15:18:26 2013 -0700

    glusterfs, gfapi: fix symbol clash
    
    The callback structures in both protocol/client and glusterfsd,
    gfapi used the same name for the actor table - gluster_cbk_actors.
    
    CBKs are required only for the management connection, and the
    actors of protocol/client are NOP functions. This supposed-to-be
    NOP function dispatch tabble is actually ending up pointing to
    the actor table of glusterfsd or gfapi.
    
    These functions, even though set wrongly, are not even expected
    to be called through the protocol/client callback path. Glusterd
    however sends the FETCHSPEC (and other) notify callbacks to *all*
    connected clients unconditionally, and there is a small period
    of time when protocol/client is connected to glusterd for
    PORTMAP query. If the FETCHSPEC callback notify is issued in
    this window of time, we end up calling the wrong actor in the
    client side resulting in a crash.
    
    Change-Id: I605ff7df64c7faf4607369bbf275aedec28e1778
    BUG: 1004091
    Signed-off-by: Anand Avati <avati>
    Reviewed-on: http://review.gluster.org/5767
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Amar Tumballi <amarts>

Comment 3 Anand Avati 2013-09-10 00:52:11 UTC
REVIEW: http://review.gluster.org/5875 (glusterfs, gfapi: fix symbol clash) posted (#1) for review on release-3.4 by Anand Avati (avati)

Comment 4 Anand Avati 2013-09-10 01:04:40 UTC
REVIEW: http://review.gluster.org/5875 (glusterfs, gfapi: fix symbol clash) posted (#2) for review on release-3.4 by Anand Avati (avati)

Comment 5 Anand Avati 2013-09-10 08:17:37 UTC
COMMIT: http://review.gluster.org/5875 committed in release-3.4 by Vijay Bellur (vbellur) 
------
commit 4e598f4745d733a496c4d252a703d3359189ad2b
Author: Anand Avati <avati>
Date:   Tue Sep 3 15:18:26 2013 -0700

    glusterfs, gfapi: fix symbol clash
    
    The callback structures in both protocol/client and glusterfsd,
    gfapi used the same name for the actor table - gluster_cbk_actors.
    
    CBKs are required only for the management connection, and the
    actors of protocol/client are NOP functions. This supposed-to-be
    NOP function dispatch tabble is actually ending up pointing to
    the actor table of glusterfsd or gfapi.
    
    These functions, even though set wrongly, are not even expected
    to be called through the protocol/client callback path. Glusterd
    however sends the FETCHSPEC (and other) notify callbacks to *all*
    connected clients unconditionally, and there is a small period
    of time when protocol/client is connected to glusterd for
    PORTMAP query. If the FETCHSPEC callback notify is issued in
    this window of time, we end up calling the wrong actor in the
    client side resulting in a crash.
    
    Change-Id: I605ff7df64c7faf4607369bbf275aedec28e1778
    BUG: 1004091
    Signed-off-by: Anand Avati <avati>
    Reviewed-on: http://review.gluster.org/5875
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

Comment 6 Niels de Vos 2014-04-17 11:47:12 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-3.5.0, please reopen this bug report.

glusterfs-3.5.0 has been announced on the Gluster Developers mailinglist [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://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137
[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.