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]

Date:	Thu, 16 Apr 2009 13:01:50 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Alexander Viro <viro@....linux.org.uk>,
	Alessio Igor Bogani <abogani@...ware.it>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>, viro@...iv.linux.org.uk
Subject: Re: [PATCH -tip] remove the BKL: Replace BKL in mount/umount
	syscalls with a mutex

On Thu, Apr 16, 2009 at 06:49:27PM +0200, Ingo Molnar wrote:
> They dont really protect anything - the patch is wrong and 
> equivalent to a plain removal of the BKL.
> 
> The only case we found to ever matter in practice is NFS: it really 
> wants to get rid of the BKL in nfsd_get_sb(). So pushing down the 
> BKL lock into per filesystems and then removing it from NFS should 
> do the trick.
> 
> Would be nice to have some tentative Ack (or, a tentative 
> non-immediate-NAK) from Al before we go touch a lot of filesystems 
> though. Stupid dont-waste-human-effort considerations and stuff.
> 
> For us, the much simpler solution would be to drop the BKL in 
> nfsd_get_sb() and go on with life without to touch a dozen or so 
> filesystems. Alessio, mind trying that too, is it a solution for 
> your testcase?

What about trying to attack it piece-mail?  ->unmount_begin is really
easy.  The only one that doesn't protect everything properly is
9p, but it doesn't protect the state variable deep down a few levels
of function calls at all.

->remount_fs should be easy enough to, we do have proper per-sb
protection here, but do_remount_sb will need a bit of an audit.
(and of course pushing lock_kernel down into the many instances and
leave the cleanup-work to the fs maintainers).

The actual mount path is more interesting as there are quite a few cases
there.  As a first step you can take lock_kernel from outside do_mount
into the various do_foo calls inside it, and then work on those piece
by piece.
--
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/