[Bugs] [Bug 1344422] New: fd leak in disperse
bugzilla at redhat.com
bugzilla at redhat.com
Thu Jun 9 15:53:30 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1344422
Bug ID: 1344422
Summary: fd leak in disperse
Product: GlusterFS
Version: 3.7.11
Component: disperse
Keywords: Triaged
Severity: medium
Assignee: bugs at gluster.org
Reporter: xhernandez at datalab.es
CC: aspandey at redhat.com, bugs at gluster.org,
pkarampu at redhat.com, xhernandez at datalab.es
Depends On: 1344396
Blocks: 1344421
+++ This bug was initially created as a clone of Bug #1344396 +++
Description of problem:
The disperse xlator uses __fd_unref() to release references to the fd. However
this function doesn't make the cleanup of the fd resources if this was the last
reference.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--- Additional comment from Pranith Kumar K on 2016-06-09 17:21:24 CEST ---
Could you give a reference to the function you are referring to where this
cleanup is not happening as we intend it to?
--- Additional comment from Xavier Hernandez on 2016-06-09 17:27:19 CEST ---
In function ec_lock_update_fd() we choose the newest fd to keep it in the lock
structure. If there's already an fd assigned, we release it using __fd_unref().
We use this function because we are already inside a region protected bye
inode->lock, so we cannot call fd_unref().
The problem is that this function doesn't do any cleanup. It only decrements
the ref counter. All cleanup is made in fd_unref().
--- Additional comment from Vijay Bellur on 2016-06-09 17:35:30 CEST ---
REVIEW: http://review.gluster.org/14683 (cluster/ec: Fix invalid __fd_unref()
call) posted (#1) for review on master by Xavier Hernandez
(xhernandez at datalab.es)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1344396
[Bug 1344396] fd leak in disperse
https://bugzilla.redhat.com/show_bug.cgi?id=1344421
[Bug 1344421] fd leak in disperse
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list