Description of problem: The following test causes the snapshot daemon to crash. 1) Create a gluster volume 2) mount the volume and create few files 3) Take snapshot(s) 4) open a file and keep the fd open for a file from one of the snapshots via uss 5) delete the snapshot to which the file opened belongs to 6) perform some operation on the fd This is because, when the snapshot is deleted, the glfs_t instance for that snapshot is also destroyed. And later when the operation on the fd is received by the snapshot daemon, it tries to access the glfs_t instance for the deleted snapshot. But since the glfs_t instance is destroyed, the pointer access causes a crash. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: https://review.gluster.org/20525 ( features/snapview-server: validate the fs instance before doing fop there) posted (#1) for review on master by Raghavendra Bhat
COMMIT: https://review.gluster.org/20525 committed in master by "Amar Tumballi" <amarts> 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>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report. glusterfs-5.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://lists.gluster.org/pipermail/announce/2018-October/000115.html [2] https://www.gluster.org/pipermail/gluster-users/