Bug 885008

Description of problem:

Upon graph change fuse migrates the fds to the new graph through the function fuse_migrate_fd in which it does the below thing.

ret = fuse_migrate_fd_open (this, basefd, oldfd, old_subvol,
                                    new_subvol, &newfdptr);
        if (ret < 0) {
                gf_log (this->name, GF_LOG_WARNING, "open corresponding to "
                        "basefd (ptr:%p inode-gfid:%s) in new graph failed "
		        "(old-subvolume:%s-%d new-subvolume:%s-%d)", basefd,
                        uuid_utoa (basefd->inode->gfid), old_subvol->name,
                        old_subvol->graph->id, new_subvol->name,
                        new_subvol->graph->id);
                goto out;
        }

        ret = fuse_migrate_locks (this, oldfd, newfdptr, old_subvol,
                                  new_subvol);
        if (ret < 0) {
                gf_log (this->name, GF_LOG_WARNING,
			"migrating locks from old-subvolume (%s-%d) to "
                        "new-subvolume (%s-%d) failed (inode-gfid:%s oldfd:%p "
			"newfd:%p)", old_subvol->name, old_subvol->graph->id,
                        new_subvol->name, new_subvol->graph->id,


At first the fd is migrated and then locks are migrated to the new graph. The newfd created in the new graph is obtained in newfdptr.

In fuse_migrate_fd_open new fd is created for the new graph, and at the end it is unrefed (thus destroying the fd too).  Next time when the same fd pointer is accessed in fuse_migrate_locks the process will segfault.

This seems to be a race condition.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: