From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ingo Molnar <mingo@elte.hu>
Cc: Alessio Igor Bogani <abogani@texware.it>,
Jonathan Corbet <corbet@lwn.net>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
LKML <linux-kernel@vger.kernel.org>,
LFSDEV <linux-fsdevel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matthew Wilcox <matthew@wil.cx>
Subject: Re: [PATCH 1/1] vfs: umount_begin BKL pushdown v2
Date: Fri, 24 Apr 2009 14:58:21 +0100 [thread overview]
Message-ID: <20090424135821.GJ8633@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20090424080634.GG24912@elte.hu>
On Fri, Apr 24, 2009 at 10:06:34AM +0200, Ingo Molnar wrote:
> You've not replied to my request (attached below) to put these
> trivial BKL-pushdown bits into a separate branch/tree and not into
> the VFS tree. You've now mixed that commit with other VFS changes.
>
> Had it been in a separate branch, and had we tested it, Linus could
> have pulled the trivial BKL pushdown bits out of normal merge order
> as well. That is not possible now.
>
> Furthermore, by doing this you are also hindering the
> tip:kill-the-BKL effort (which has been ongoing for a year chipping
> away at various BKL details) which facilitated these changes.
> Alessio did these fixes to fix bugs he can trigger in that tree.
>
> You've also not explained why you have done it this way. It would
> cost you almost nothing to apply these bits into a separate branch
> and merge that branch into your main tree. Lots of other maintainer
> are doing that.
>
> So if you've done this by mistake, i'd like to ask you to reconsider
> and put these bits into a separate, stable-commit-ID branch. If
> you've done this intentionally, i'd like you to explain the reasons
> for it, instead of just doing it silently without explanation.
>
> Anwyay, if there's no resolution, i'll apply Alessio's fixes with a
> different commit ID, to not hold up the rather useful work that is
> going on in the kill-the-BKL tree. Later on i'll have to rebase that
> portion of the tree to avoid duplicate commit IDs. I just wanted to
> put it on the record why i have to do that rebase.
Good grief... You have the commit ID, git fetch + git-cherry-pick would
take two lines to type instead of more than a screenful.
This patch is certainly trivial enough to go into the mainline at any point.
Including "right now". However, the stuff to follow it might get more
convoluted and I wouldn't argue for pushing it before the next merge window.
It's not just the "push BKL down there" - that I could simply do right
now and ACK pushing it to Linus/push myself. Unless I'm mistaken, you
want to pull the subsequent "remove BKL in foofs" bits as well and those
are almost certainly going to get entangled with other stuff.
I'm not particulary against a separate branch for all that stuff (including
the remount changes that'll be needed, etc.). The question is, what merge
time are you aiming for and how much VFS stuff are you willing to tolerate
in that branch?
Details, please...
next prev parent reply other threads:[~2009-04-24 13:58 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-23 19:12 [PATCH 0/5 -tip] umount_begin BKL pushdown Alessio Igor Bogani
2009-04-23 19:12 ` [PATCH 1/5 -tip] 9p: " Alessio Igor Bogani
2009-04-23 19:12 ` [PATCH 2/5 -tip] cifs: " Alessio Igor Bogani
2009-04-23 19:12 ` [PATCH 3/5 -tip] fuse: " Alessio Igor Bogani
2009-04-23 19:12 ` [PATCH 4/5 -tip] nfs: " Alessio Igor Bogani
2009-04-23 19:12 ` [PATCH 5/5 -tip] vfs: Don-t call umount_begin with BKL held Alessio Igor Bogani
2009-04-23 19:15 ` [PATCH 2/5 -tip] cifs: umount_begin BKL pushdown Al Viro
2009-04-23 19:19 ` Matthew Wilcox
2009-04-24 7:06 ` [PATCH 0/1] vfs: umount_begin BKL pushdown v2 Alessio Igor Bogani
2009-04-24 7:06 ` [PATCH 1/1] " Alessio Igor Bogani
2009-04-24 7:13 ` Al Viro
2009-04-24 7:15 ` Al Viro
2009-04-24 8:48 ` Christoph Hellwig
2009-04-24 7:18 ` Al Viro
2009-04-24 7:41 ` Alessio Igor Bogani
2009-04-24 8:06 ` Ingo Molnar
2009-04-24 8:50 ` Christoph Hellwig
2009-04-24 9:16 ` Frédéric Weisbecker
2009-04-24 17:50 ` Christoph Hellwig
2009-04-24 18:55 ` Al Viro
2009-04-24 19:02 ` Christoph Hellwig
2009-04-24 20:43 ` Al Viro
2009-04-24 22:07 ` Ingo Molnar
2009-04-24 22:49 ` Ingo Molnar
2009-04-24 13:58 ` Al Viro [this message]
2009-04-24 22:19 ` Ingo Molnar
2009-04-25 7:16 ` Al Viro
2009-04-23 19:18 ` [PATCH 0/5 -tip] umount_begin BKL pushdown Al Viro
2009-04-23 21:32 ` Ingo Molnar
2009-04-24 1:57 ` Stephen Rothwell
2009-04-24 14:31 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090424135821.GJ8633@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=a.p.zijlstra@chello.nl \
--cc=abogani@texware.it \
--cc=corbet@lwn.net \
--cc=fweisbec@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).