diff options
author | Raghavendra Bhat <raghavendra@redhat.com> | 2018-10-31 16:31:35 -0400 |
---|---|---|
committer | mohammed rafi kc <rkavunga@redhat.com> | 2018-11-20 11:21:36 +0000 |
commit | 650b5c5271abeb0eef59ac1ebb0ea3c8c37023ab (patch) | |
tree | ea7619b7e33818e146ce04d368a072fb5004a865 /xlators/protocol | |
parent | 751b14f2bfd40e08ad395ccd98c6eb0a41ac4e91 (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/protocol')
0 files changed, 0 insertions, 0 deletions