linux-kernel - Re: [PATCH 1/1] vfs: umount

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:	Fri, 24 Apr 2009 13:50:25 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Fr?d?ric Weisbecker <fweisbec@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Al Viro <viro@...iv.linux.org.uk>,
	Alessio Igor Bogani <abogani@...ware.it>,
	Jonathan Corbet <corbet@....net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	LFSDEV <linux-fsdevel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matthew Wilcox <matthew@....cx>
Subject: Re: [PATCH 1/1] vfs: umount_begin BKL pushdown v2

On Fri, Apr 24, 2009 at 11:16:18AM +0200, Fr?d?ric Weisbecker wrote:
> I disagree with you. The kill-the-BKL tree does not only aggregate patches
> to turn the BKL into more traditional locks. The Bkl has been
> converted to a common mutex in
> this tree, making it losing its common horrid properties:
> 
> - release/reacquire on schedule
> - not preemptable
> - can be reacquired recursively by a same task
> 
> Such a basis is very useful because we can easily find these places
> which won't support a usual lock conversion without reworking the
> locking scheme.
> This is a necessary preliminary for the Bkl removal.
> All the places which have been designed very tightly with Bkl
> properties are rapidly detected
> with lockdep in this tree and reworked, still using lockdep, code
> reviewing and the help of
> this Bkl-to-mutex conversion.
> 
> The work done with this tree can be merged inside and also on the
> matching subsytem tree for
> each patchset. That's a very sane workflow IMHO.

Having a working tree for debugging stuff is fine, but the point is
that it should never be pulled into mainline and probably frequently
reabsed to avoid cruft.  In that case there's really no point in
creating branches to share pieces of tree history, just apply the patch
locally if you think you want it and merge or rebase once mainline gets
the patch.

Al frequently rebases the vfs tree, btw - so even if it was a separate
branch now there's a fair chance it would end up in mainline with a
different commit id.
--
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/