linux-kernel - Re: [PATCH] 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:	Tue, 14 Sep 2010 13:20:22 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	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>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] Remove BKL from fs/locks.c

On Tue, Sep 14, 2010 at 1:06 PM, Arnd Bergmann <arnd@...db.de> wrote:
>
> Christoph already made it clear that it cannot go upstream
> like this and Stephen said he consequently didn't want it
> in -next either. It may still be material for -mm or -rt,
> or just anyone who wants to test a kernel with CONFIG_BKL
> disabled.

I think something like this would be acceptable with that whole config
option removed.

That would not help your particular "test without BKL at all" case,
but basically I would suggest something like the following:

 - do the unconditional conversion to the new spinlock, so that
fs/locks.c is internally consistent and conceptually works without the
BKL at all.

 - remove all the EXPORT_SYMBOL()s

 - create wrapper functions named xyzzy_bkl() (perhaps in a different
fs/bkl.c file or whatever - or maybe just in the same file that you do
the bkl for CONFIG_BKL in the first place) that wrap the fs/locks.c
symbols with the kernel lock (so now those wrappers will take _both_
the BKL and the real spinlock)

 - fix up all modular users mindlessly to call the bkl version, and
ship it that way for one release

End result: anybody who uses the old exports will just not link at
all, and all in-kernel users (ie lockd etc) will now very explicitly
have that xyz_bkl() use.

After that one release, we can re-introduce the old names without the
bkl, and let filesystems and other subsystems just decide that they
don't want the bkl version one by one. So that first phase would be
basically a no-op with an interface rename just so that the rest could
then be done piece-meal.

                           Linus
--
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/