summaryrefslogtreecommitdiffstats
path: root/xlators/features
diff options
context:
space:
mode:
authorRaghavendra Bhat <raghavendra@redhat.com>2018-10-31 16:31:35 -0400
committermohammed rafi kc <rkavunga@redhat.com>2018-11-20 11:21:36 +0000
commit650b5c5271abeb0eef59ac1ebb0ea3c8c37023ab (patch)
treeea7619b7e33818e146ce04d368a072fb5004a865 /xlators/features
parent751b14f2bfd40e08ad395ccd98c6eb0a41ac4e91 (diff)
snapview-server: close the gfapi handle present in a forgotten inode
Currently, the snapdaemon can reach the lru limit of the inode table and start sending forgets on the inodes that are least recently used. snapview-server maintains the mapping between the domain of the snapdaemon and the gfapi instance which it uses to access the snapshots via a handle that is stored in the inode context of snapdaemon's inode. The handle is glfs_h_object structure which itself points to the actual inode present in the gfapi world. But, when snapview-server receives forget on a inode, it deleted the inode context without actually closing the handle it had obtained to map the inode from snapdaemon to the inode in gfapi world. So, this change makes sure that, the handle is closed as part of the inode forget. And this closure of the handle will result in gfapi world receiving forget and unref on its corresponding inode. But care must be taken to ensure before the closure to ensure that the gfapi instance from which the handle came from, is still valid and not destroyed. Otherwise, sending a forget downward to the gfapi world might result in the access of freed pointers. Hence, the snapview-server xlator first checks whether that gfapi instance is still there or not and then proceeds with closure of the handle. Change-Id: Ia7bb45112d0c651cc95f2e54d33d925dbd6955b0 fixes: bz#1646728 Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
Diffstat (limited to 'xlators/features')
-rw-r--r--xlators/features/snapview-server/src/snapview-server.c22
1 files changed, 22 insertions, 0 deletions
diff --git a/xlators/features/snapview-server/src/snapview-server.c b/xlators/features/snapview-server/src/snapview-server.c
index 270d40a4ed5..1ce3dcfed54 100644
--- a/xlators/features/snapview-server/src/snapview-server.c
+++ b/xlators/features/snapview-server/src/snapview-server.c
@@ -1368,6 +1368,28 @@ svs_forget(xlator_t *this, inode_t *inode)
if (inode_ctx->snapname)
GF_FREE(inode_ctx->snapname);
+ /*
+ * glfs_h_close leads to unref and forgetting of the
+ * underlying inode in the gfapi world. i.e. the inode
+ * which inode_ctx->object points to.
+ * As of now the only possibility is, this forget came as a
+ * result of snapdaemon's inode table reaching the lru
+ * limit and receiving forget as a result of purging of
+ * extra inodes that exceeded the limit. But, care must
+ * be taken to ensure that, the gfapi instance to which
+ * the glfs_h_object belongs to is not deleted. Otherwise
+ * this might result in access of a freed pointer.
+ * This will still be helpful in reducing the memory
+ * footprint of snapdaemon when the fs instance itself is
+ * valid (i.e. present and not destroyed due to either snap
+ * deactivate or snap delete), but the lru limit is reached.
+ * The forget due to lru limit will make the underlying inode
+ * being unrefed and forgotten.
+ */
+ if (svs_inode_ctx_glfs_mapping(this, inode_ctx)) {
+ glfs_h_close(inode_ctx->object);
+ inode_ctx->object = NULL;
+ }
GF_FREE(inode_ctx);
out: