On Thu, Dec 14, 2006 at 06:04:42PM -0500, J. Bruce Fields wrote:
> By the way, one other issue I think we'll need to resolve:
>
> On Wed, Dec 06, 2006 at 12:34:11AM -0500, J. Bruce Fields wrote:
> > +/**
> > + * vfs_cancel_lock - file byte range unblock lock
> > + * @filp: The file to apply the unblock to
> > + * @fl: The lock to be unblocked
> > + *
> > + * FL_CANCELED is used to cancel blocked requests
> > + */
> > +int vfs_cancel_lock(struct file *filp, struct file_lock *fl)
> > +{
> > + int status;
> > + struct super_block *sb;
> > +
> > + fl->fl_flags |= FL_CANCEL;
> > + sb = filp->f_dentry->d_inode->i_sb;
> > + if (sb->s_export_op && sb->s_export_op->lock)
> > + status = sb->s_export_op->lock(filp, F_SETLK, fl);
> > + else
> > + status = posix_unblock_lock(filp, fl);
> > + fl->fl_flags &= ~FL_CANCEL;
> > + return status;
> > +}
>
> So we're passing cancel requests to the filesystem by setting an
> FL_CANCEL flag in fl_flags and then calling the lock operation. I think
> Trond has said he'd rather keep fl_flags for permanent characteristics
> of the lock in question, rather than as a channel for passing arguments
> to lock operations. Also, the GFS patch isn't checking FL_CANCEL, so
> that's a bug.
This should be a separate operation. Either a new command for
->lock or a completely new operation.
-
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
