Re: [PATCH 1/1] vfs: umount_begin BKL pushdown v2

Ingo Molnar
2009-04-24T22:07:44Z

* Christoph Hellwig <hch@infradead.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