Hi,
We observed a ref leak of cache-inode entry (in V2.3-stable codepath) in
case if there are multiple locks issued on that entry which may get
merged. Attached the fix for it.
Kindly review and merge it into V2.3-stable branch.
Thanks,
Soumya
>From df75e83d4cc2ba03a69564807e7a890967505e64 Mon Sep 17 00:00:00 2001
From: Soumya Koduri <skod...@redhat.com>
Date: Tue, 27 Sep 2016 14:45:41 +0530
Subject: [PATCH] SAL: Ref leak in lock merge codepath
In state_lock(), we pin the cache_entry before processing the
lock operation. This shall be unref'ed at the end of the
operation unless it is the first lock entry for that cache
entry.
But in case of overlapping locks, in merge_lock_entry(), once
we merge the locks, we remove the older one. This could lead
to empty lock list for that cache_entry, but with the earlier
ref not taken out resulting in a leak.
The fix is to unpin the cache entry if the lock entry removed
was the last one in its lock list.
Change-Id: I9ed9e9ad8115d1e3c5dcc28bcc8e733b94b82de2
Signed-off-by: Soumya Koduri <skod...@redhat.com>
---
src/SAL/state_lock.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/SAL/state_lock.c b/src/SAL/state_lock.c
index 1910077..22564ed 100644
--- a/src/SAL/state_lock.c
+++ b/src/SAL/state_lock.c
@@ -948,6 +948,13 @@ static void merge_lock_entry(struct state_hdl *ostate,
LogEntry("Merged", lock_entry);
LogEntry("Merging removing", check_entry);
remove_from_locklist(check_entry);
+
+ /* if check_entry was the last lock entry, unpin
+ * the cache entry */
+ if (glist_empty(&entry->object.file.lock_list)) {
+ cache_inode_dec_pin_ref(entry, false);
+ cache_inode_lru_unref(entry, LRU_FLAG_NONE);
+ }
}
}
--
2.5.0
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
