[Pvfs2-cvs] commit by pcarns in pvfs2-1/src/apps/kernel/linux:
pvfs2-client-core.c
CVS commit program
cvs at parl.clemson.edu
Tue May 13 09:46:28 EDT 2008
Update of /projects/cvsroot/pvfs2-1/src/apps/kernel/linux
In directory parlweb1:/tmp/cvs-serv19299
Modified Files:
pvfs2-client-core.c
Log Message:
The umount request in pvfs2-client was not reposting an unexpected device
request, which means that all outstanding operations would be exhausted
after 64 umounts (and hang the pvfs2-client-core daemon). This changes
makes umount act like some of the more normal operation types.
Suspect a similar problem in other operations that are handled inline (like
perf monitoring and other /proc/sys/pvfs2 handlers) but will address those
separately.
Fixes bug reported by Bart Taylor:
http://www.beowulf-underground.org/pipermail/pvfs2-developers/2008-May/004018.html
Index: pvfs2-client-core.c
===================================================================
RCS file: /projects/cvsroot/pvfs2-1/src/apps/kernel/linux/pvfs2-client-core.c,v
diff -p -u -r1.94 -r1.95
--- pvfs2-client-core.c 7 May 2008 19:12:51 -0000 1.94
+++ pvfs2-client-core.c 13 May 2008 13:46:28 -0000 1.95
@@ -1169,7 +1169,9 @@ static PVFS_error service_fs_umount_requ
ok:
PVFS_util_free_mntent(&mntent);
- write_inlined_device_response(vfs_request);
+ /* let handle_unexp_vfs_request() function detect completion and handle */
+ vfs_request->op_id = -1;
+
return 0;
fail_downcall:
gossip_err(
@@ -2666,6 +2668,8 @@ static inline void package_downcall_memb
}
break;
}
+ case PVFS2_VFS_OP_FS_UMOUNT:
+ break;
default:
gossip_err("Completed upcall of unknown type %x!\n",
vfs_request->in_upcall.type);
@@ -2855,6 +2859,7 @@ static inline PVFS_error handle_unexp_vf
calls that are serviced inline.
*/
case PVFS2_VFS_OP_FS_UMOUNT:
+ posted_op = 1;
ret = service_fs_umount_request(vfs_request);
break;
case PVFS2_VFS_OP_PERF_COUNT:
More information about the Pvfs2-cvs
mailing list