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:
quoted text
> +/**
> + * 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.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs