path: root/xlators/protocol/client
diff options
authorRaghavendra Bhat <>2018-10-31 16:31:35 -0400
committermohammed rafi kc <>2018-11-20 11:21:36 +0000
commit650b5c5271abeb0eef59ac1ebb0ea3c8c37023ab (patch)
treeea7619b7e33818e146ce04d368a072fb5004a865 /xlators/protocol/client
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 <>
Diffstat (limited to 'xlators/protocol/client')
0 files changed, 0 insertions, 0 deletions