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] [day] [month] [year] [list]

Date:	Wed, 22 Apr 2009 13:28:15 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Matthew Wilcox <willy@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>
Subject: Re: [PATCH -tip] remove the BKL: Replace BKL in mount/umount
	syscalls with a mutex

On Fri, Apr 17, 2009 at 11:44:31AM -0700, Matthew Wilcox wrote:
> 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.

It's only lockd that actually runs *entirely* under the BKL--and lockd
obviously has a close relationship with the locks.c code, so there's a
fear of (unknown) dependencies there.

Also, more concretely (and what you probably had in mind), there are a
couple places where the nfs client or server explicitly take the bkl
just to traverse the lock list.

> 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.

I've been saying for a while I'd look into this, but keep getting
distracted, apologies.... I'll see if I can at least deal with the
obvious nfs client/server lock list traversals this time around.

--b.
--
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/