linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] more vfs bits
Date: Sun, 22 Feb 2015 00:51:25 +0000	[thread overview]
Message-ID: <20150222005125.GX29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFwZ9X2XYzwkTvxANOMN8T9aynUCLCr5wKdahfdOX5fXig@mail.gmail.com>

On Sat, Feb 21, 2015 at 02:45:34PM -0800, Linus Torvalds wrote:
> So I've pulled this, but quite frankly, I think I will unpull it again
> unless you actually state *what* the advantages of this pointless
> series of endless patches are.

> And no, that "explanation" in commit b717805b3c8b is not an
> explanation. Why should filesystems have to know/care. Any use of
> "fs_inode()" clearly does *not* specify upper/lower, so what the f*ck
> is the advantage of that helper wrt just making the rule be that
> "dentry->d_inode" is that unspecified thing.
> 
> Explain it, or that crap gets undone.

Use of fs_inode does not specify upper/lower; it's choice of dentry_inode() vs.
fs_inode().  And d_inode() side of that pile is what I didn't cherry-pick
from David's tree - it was too massive already.

FWIW, I probably should've collapsed the per-fs patches together, or
held them back until the next cycle; I understand why David did them
that way (less painful rebasing that stuff), but once they switch from
"try to stay sane while developing" to "into the tree it goes" mode,
they ought to have been collapsed together.  And that's something I should
have done - my fault.

Filesystems (non-layered ones) should *not* care; this fs_inode() thing is
exactly what we do right now and, unlike dentry_inode(), it is intended to
stay that way.  And yes, we could've bloody well have left it as ->d_inode;
it's no more than an annotation.  What it gives is a way to keep track of
the accesses that remain to be annotated.

Looking at that queue, it might make sense to hold back everything in that
series past "fanotify: Fix up scripted S_ISDIR/S_ISREG/S_ISLNK conversions"
for now - keep in in vfs.git for the next cycle.  My reason for pushing those
now had been no better than wanting to be rid of the trivial bits to make
life a bit easier for the next couple of months, avoiding fun on on each
conflict with every actively changing filesystem.  With the bulk of such
places annotated at once, the work would be limited to VFS proper plus
a bit of whack-a-mole in the end of cycle, pretty much consisting of annotating
the new ->d_inode instances in filesystems (all to fs_inode(), of course).
But that should've been spelled out in pull request *and* done in one
commit instead of that long tail.  Again, my apologies.

  parent reply	other threads:[~2015-02-22  0:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-21  3:34 [git pull] more vfs bits Al Viro
2015-02-21 22:45 ` Linus Torvalds
2015-02-21 22:48   ` Linus Torvalds
2015-02-22  0:23   ` David Howells
2015-02-22  0:59     ` Al Viro
2015-02-22  0:51   ` Al Viro [this message]
2015-02-22  1:34     ` Linus Torvalds
2015-02-22  2:02       ` Al Viro
2015-02-22  2:11         ` Al Viro
2015-02-22  2:19         ` Linus Torvalds
2015-02-22  2:51           ` Al Viro
2015-02-22  3:16             ` Linus Torvalds
2015-02-22  8:51               ` Al Viro
2015-02-22  9:32                 ` Sedat Dilek
2015-02-22  9:37                   ` Al Viro
2015-02-22 10:36                     ` Sedat Dilek
2015-02-22 15:05                       ` Sedat Dilek
2015-02-22 15:12                         ` Sedat Dilek
2015-02-22 13:22                     ` Sedat Dilek
2015-02-22 13:23                       ` Sedat Dilek
2015-02-22 12:54               ` David Howells
2015-02-22 16:46                 ` [git pull] more vfs bits, updated Al Viro
2015-02-22 20:10                   ` Sedat Dilek
2015-02-22 12:44         ` [git pull] more vfs bits David Howells
2015-02-22 12:39     ` David Howells
2015-02-22 12:30   ` David Howells
2015-02-22  0:18 ` David Howells
2015-02-22  1:14   ` Linus Torvalds
2015-02-22  1:32     ` Al Viro
  -- strict thread matches above, loose matches on Subject: below --
2013-03-03 16:04 Al Viro

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=20150222005125.GX29656@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).