On Sat, Feb 03, 2007 at 04:32:05PM -0800, Trond Myklebust wrote: > On Sat, 2007-02-03 at 00:33 -0500, J. Bruce Fields wrote: > > From: J. Bruce Fields <bfields@xxxxxxxxxxxxxxxxxxxxx> - unquoted > > +int vfs_test_lock(struct file *filp, struct file_lock *fl, struct file_lock *conf) > > +{ > > + int error; > > + > > + conf->fl_type = F_UNLCK; > > + if (filp->f_op && filp->f_op->lock) { > > + __locks_copy_lock(conf, fl); > > + error = filp->f_op->lock(filp, F_GETLK, conf); > > + if (conf->fl_ops && conf->fl_ops->fl_release_private) > > + conf->fl_ops->fl_release_private(conf); > > Why are you adding in a "release" call here? Is there any reason why a > GETLK would want to return private data from the filesystem to the VFS? I'm not adding it--it's already there in the current code for fcntl_getlk(). I looked over the nfsv4 implementation of ->lock in the getlk case, and it looks to me like it does in fact return the lock with private data still set, and counts on the VFS to release it. But I was just skimming and may have overlooked something. --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html