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:	Sat, 25 Apr 2009 00:07:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Fr?d?ric Weisbecker <fweisbec@...il.com>,
	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


* Christoph Hellwig <hch@...radead.org> wrote:

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

Btw., doing that can (and will) destroy Git history and is pretty 
explicitly discouraged.

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

So did i get you right, you are advocating people to rebase their 
trees because the VFS tree is rebased often? That's pretty 
backwards.

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