[Bugs] [Bug 1602070] [SNAPSHOT] snapshot daemon crashes if a fd from a deleted snapshot is accessed
bugzilla at redhat.com
bugzilla at redhat.com
Fri Aug 24 04:20:55 UTC 2018
https://bugzilla.redhat.com/show_bug.cgi?id=1602070
--- Comment #2 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/20525 committed in master by "Amar Tumballi"
<amarts at redhat.com> with a commit message- features/snapview-server:
validate the fs instance before doing fop there
PROBLEM:
========
USS design depends on snapview-server translator communicating with each
individual snapshot via gfapi. So, the snapview-server xlator maintains
the glfs instance (thus the snapshot) to which a inode belongs to by
storing it inside the inode context.
Suppose, a file from a snapshot is opened by a application, and the fd
is still valid from application's point of view (i.e. application has
not yet closed fd). Now, if the snapshot to which the opened file
belongs to is deleted, then the glfs_t instance corresponding to the
snapshot is destroyed by snapview-server as part of snap deletion.
But now, if the application does IO on the fd it has kept open, then
snapview server tries to send that request to the corresponding snap
via glfs instance for that snapshot stored in the inode context for
the file on which the application is sending the fop. And this results
in freed up glfs_t pointer being accessed and causes a segfault.
FIX:
===
For fd based operations, check whether the glfs instance that the inode
contains in its context, is still valid or not.
For non fd based operations, usually lookup should guarantee that. But
if the file was already looked up, and the client accessing the snap data
(either NFS, or native glusterfs fuse) does not bother to send a lookup
and directly sends a path based fop, then that path based fop should
ensure that the fs instance is valid.
Change-Id: I881be15ec46ecb51aa844d7fd41d5630f0d644fb
updates: bz#1602070
Signed-off-by: Raghavendra Bhat <raghavendra at redhat.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list