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>

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: