linux-kernel - Re: [PATCH 2/2] [RFC] Remove BKL from fs/locks.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Apr 2010 21:14:49 -0700
From:	Brad Boyer <flar@...andria.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Matthew Wilcox <willy@...ux.intel.com>,
	Christoph Hellwig <hch@....de>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, John Kacur <jkacur@...hat.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 2/2] [RFC] Remove BKL from fs/locks.c

On Wed, Apr 14, 2010 at 10:36:24PM +0200, Arnd Bergmann wrote:
> From: Matthew Wilcox <willy@...ux.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@...andria.com

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