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 <[EMAIL PROTECTED]> - 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
