On Wed, Apr 14, 2010 at 10:36:24PM +0200, Arnd Bergmann wrote:
quoted text
> From: Matthew Wilcox <willy@linux.intel.com>
> 
> I've taken a patch originally written by Matthew Wilcox and
> ported it to the current version. It seems that there were
> originally concerns that this breaks NFS, but since Trond
> has recently removed the BKL from NFS, my naive assumption
> would be that it's all good now, despite not having tried to
> understand what it does.
> 
> Original introduction from Willy:
> 
>    I've been promising to do this for about seven years now.
> 
>    It seems to work well enough, but I haven't run any serious stress
>    tests on it.  This implementation uses one spinlock to protect both lock
>    lists and all the i_flock chains.  It doesn't seem worth splitting up
>    the locking any further.
> 
>    I had to move one memory allocation out from under the file_lock_lock.
>    I hope I got that logic right.  I'm rather tempted to split out the
>    find_conflict algorithm from that function into something that can be
>    called separately for the FL_ACCESS case.
> 
>    I also have to drop and reacquire the file_lock_lock around the call
>    to cond_resched().  This was done automatically for us before by the
>    special BKL semantics.
> 
>    I had to change vfs_setlease() as it relied on the special BKL ability
>    to recursively acquire the same lock.  The internal caller now calls
>    __vfs_setlease and the exported interface acquires and releases the
>    file_lock_lock around calling __vfs_setlease.
> 
>    I should probably split out the removal of interruptible_sleep_on_locked()
>    as it's basically unrelated to all this.

Don't we need to have access to this new lock from modules? In particular,
nfsd/lockd currently call lock_kernel to be able to safely access i_flock.
This would seem to imply that they would either need new functions inside
locks.c to do the same work or export the new lock functions. It seems
easiest to just do EXPORT_SYMBOL on the new lock/unlock functions added
in this patch, but I do understand if that isn't desireable.

	Brad Boyer
	flar@allandria.com

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/