linux-kernel - Re: [PATCH -tip] remove the BKL: Replace BKL in mount/umount syscalls with a mutex

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]

Message-ID: <20090417184431.GB3719@linux.intel.com>
Date:	Fri, 17 Apr 2009 11:44:31 -0700
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jonathan Corbet <corbet@....net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, Al Viro <viro@...IV.linux.org.uk>,
	Alessio Igor Bogani <abogani@...ware.it>,
	Alexander Viro <viro@....linux.org.uk>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"J. Bruce Fields" <bfields@...ldses.org>
Subject: Re: [PATCH -tip] remove the BKL: Replace BKL in mount/umount
	syscalls with a mutex

On Fri, Apr 17, 2009 at 11:03:31AM -0700, Linus Torvalds wrote:
> Hmm. It might also just be my fevered imagination. I'd like to say it was 
> Matthew Wilcox, but really, my mind is going.
> 
> Ahh. Bug google backs me up. As long as I have google, I can keep 
> Alzheimer's at bay: "Negative scalability by removal of lock_kernel()" 
> thread on lkml back in October 2000. After we had actually done the BKL 
> removal.
> 
> So we actually did apply it (in 2.4.0-test9, and then reverted it again 
> (in -test11, I think). Google for "file_lock_sem fs/locks.c" and see some 
> of the discussion. The end result was to go back to the BKL due to Apache 
> slowdowns.

That's some good ancient history ;-)  It probably would make sense to
use a mutex rather than the BKL these days now that we spin on mutexes
if the other process is running.  Plus, I don't think modern Apache uses
file locks any more.

There was another attempt to remove the BKL from locks.c by Dave Hansen
a few years later.  That one foundered on the proposed locking scheme
being unadulterated crap; I seem to remember pointing out that it was
gathering O(n^2) locks ...

> But I seem to remember a later patch (in the last year or two) from Willy 
> too. Google doesn't help me, so that's probably just my fevered mind. But 
> I'm cc'ing Willy anyway.

Fortunately, this patch wasn't the product of a fevered anything.  It
was in response to the performance regressions I introduced by
introducing the generic semaphores that were too fair.

It didn't deal with the really knotty problem which was the NFS server
still running under the BKL and relying on the BKL to prevent other
CPUs from messing with the list of locks.

Since the problem turned out to be the TTY layer and not the file
locking code, we just dropped the patch, but if we'd like to resurrect
it again, we need to talk to the NFS folks.  Probably Bruce Fields is
the appropriate sucker.
--
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/