Bug 1392288
| Summary: | gfapi clients crash while using async calls due to double fd_unref | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Raghavendra Talur <rtalur> |
| Component: | libgfapi | Assignee: | Raghavendra Talur <rtalur> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Sudhir D <sdharane> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.8 | CC: | bugs, sdharane |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | glusterfs-3.8.6 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1391086 | Environment: | |
| Last Closed: | 2016-11-29 09:37:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1391086, 1392289 | ||
| Bug Blocks: | 1384412, 1391093, 1392286 | ||
|
Description
Raghavendra Talur
2016-11-07 06:37:31 UTC
REVIEW: http://review.gluster.org/15779 (gfapi: async fops should unref in callbacks) posted (#1) for review on release-3.8 by Raghavendra Talur (rtalur) COMMIT: http://review.gluster.org/15779 committed in release-3.8 by Raghavendra Talur (rtalur) ------ commit 5592c3c65b57db11f228e2ee263be3b6c4a45f84 Author: Raghavendra Talur <rtalur> Date: Wed Nov 2 19:51:26 2016 +0530 gfapi: async fops should unref in callbacks If fd is unref'd at the end of async call then the unref in cbks would lead to double unref and possible crash. Removing duplicate unrefs. Added unref only in failure cases. A simple test case has been added to test async write case. Need to extend the same for other async APIs too. Details: All glfd based calls in libgfapi, except for glfs_open and glfs_close, behave in the same way. At the start of the operation, they take a ref on glfd and fd. At the end of the operation, they unref it. Async calls are a little different as they unref in the cbk function. A successfull open call does not unref either the glfd or fd, thereby functioning as a reference for a OPEN file object. glfs_close makes a syncop_flush call sandwiched between a fd ref and unref(this can be removed, more on this below), followed by a call to glfs_mark_glfd_for_deletion which unrefs glfd and also calls glfs_fd_destroy as a release function thereby doing a unref on fd too. Functionally, there is no problem with how everything works when as described above. However, it is a little non-intuitive that we need to perform a fd_unref as a consequence of a implicit fd_ref that happens within glfs_resolve_fd. As we perform a GF_REF_GET(glfd) at the start of every operation, it would be worthwhile to remove the fd_ref that glfs_resovle_fd takes and do away with explicit fd_unref()s at the end of every operation. This is the same reason why we don't need the fd_ref in glfs_close. This is however not in the scope of this patch. Change-Id: I86b1d3b2ad846b16ea527d541dc82b5e90b0ba85 BUG: 1392288 Signed-off-by: Raghavendra Talur <rtalur> Reviewed-on: http://review.gluster.org/15768 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: Rajesh Joseph <rjoseph> Reviewed-by: Xavier Hernandez <xhernandez> Reviewed-by: soumya k <skoduri> Reviewed-by: Prasanna Kumar Kalever <pkalever> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Shyamsundar Ranganathan <srangana> (cherry picked from commit e65738818dd22462ec00dda021566654d1c702b1) Reviewed-on: http://review.gluster.org/15779 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.8.6, please open a new bug report. glusterfs-3.8.6 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://www.gluster.org/pipermail/packaging/2016-November/000217.html [2] https://www.gluster.org/pipermail/gluster-users/ |