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.
--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
