From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH] Remove BKL from fs/locks.c Date: Tue, 14 Sep 2010 17:55:56 -0400 Message-ID: <1284501356.10782.139.camel@heimdal.trondhjem.org> References: <201009142206.54130.arnd@arndb.de> <201009142239.02904.arnd@arndb.de> <201009142324.16074.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Matthew Wilcox , Christoph Hellwig , "J. Bruce Fields" , Miklos Szeredi , Frederic Weisbecker , Ingo Molnar , John Kacur , Stephen Rothwell , Andrew Morton , Thomas Gleixner To: Arnd Bergmann Return-path: In-Reply-To: <201009142324.16074.arnd@arndb.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2010-09-14 at 23:24 +0200, Arnd Bergmann wrote: > On Tuesday 14 September 2010 22:53:31 Linus Torvalds wrote: > > Oh well. I guess there's no incremental way to do things sanely. And > > nobody has patches to fix those users, I guess. > > The only critical user is fs/lockd, I can easily handle the rest. > When I talked to Bruce and Trond during LinuxCon, they told me that > it should be possible to separate the bits of fs/lockd that lock > against fs/locks.c and convert the former to use lock_flocks(). The NFSv4 client is quite ready to just switch to using lock_flocks() now. There is nothing that depends on the magical properties of the BKL. I do also have someone working on BKL removal for the NLM/lockd client and am hoping that should be ready in a couple of weeks time. The timeline for the server is up to Bruce, however. > That would be enough to actually apply this patch without the > nasty CONFIG_BKL check and with changes to the few other > consumers of file locks. My original plan was to have my current > patch in -next until that happens. Would it be possible to at least merge a patch that defines lock_flocks() (even if it just is an alias for lock_kernel()), so that we can convert those bits of the lock recovery code that need to peek into the inode->i_flock list ASAP? Cheers Trond