From: "J. R. Okajima" <hooanon05g@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Miklos Szeredi <miklos@szeredi.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>
Subject: Re: [GIT PULL] overlayfs update for 4.14
Date: Sun, 17 Sep 2017 23:38:15 +0900 [thread overview]
Message-ID: <14181.1505659095@jrobl> (raw)
In-Reply-To: <CA+55aFzzKg17=RYTUomF9Fsy0mM5Acqkak0EZJPivZ5+oZErwA@mail.gmail.com>
Linus Torvalds:
> On Wed, Sep 13, 2017 at 11:46 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > d_real() is currently is *the* overlayfs-op:
>
> I know. And it's ugly as #%^! hell.
>
> We don't want to make it uglier.
>
> And honestly, if you think that "it's only for overlayfs, so I can do
> anything I damn well want to this p[iece of shit" is valid, then I
> want to re-educate you. That is *not* how the VFS layer works.
Miklos,
I've just read your experimental patch to remove ->d_real(). I believe
it is the way to go. Moreover I'd suggest you to re-consider these
things.
- d_real_inode(), d_backing_inode(), and locks_inode()
I don't think it a good idea for VFS and other modules to care "which
inode I should use" issue. Ideally they should call d_inode() and
file_inode() only as they used to.
- RENAME_WHITEOUT flag for user-space
Why does this flag visible to users? It is a pure internal flag, isn't
it? When and what for do users specify this flag?
Git-grepping the overlayfs related changes in other modules, I'd also
suggest you to re-consider these.
v4.2
4bacc9c 2015-06-19 overlayfs: Make f_path always point to the overlay and f_inode to the underlay
v4.6
54d5ca8 2016-05-10 vfs: add vfs_select_inode() helper
d101a12 2016-03-26 fs: add file_dentry()
v4.7
a118084 2016-05-20 vfs: add d_real_inode() helper
v4.8
c1892c3 2016-08-03 vfs: fix deadlock in file_remove_privs() on overlayfs
v4.9
4d0c5ba 2016-09-16 vfs: do get_write_access() on upper layer of overlayfs
c568d68 2016-09-16 locks: fix file locking on overlayfs
f3fbbb0 2016-09-16 fsnotify: support overlayfs
598e3c8 2016-09-16 vfs: update ovl inode before relatime check
v4.12
78757af 2017-04-20 vfs: ftruncate check IS_APPEND() on real upper inode
v4.13
ad0af71 2017-07-04 vfs: introduce inode 'inuse' lock
J. R. Okajima
prev parent reply other threads:[~2017-09-17 14:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-13 14:05 [GIT PULL] overlayfs update for 4.14 Miklos Szeredi
2017-09-13 16:25 ` Linus Torvalds
2017-09-14 6:46 ` Miklos Szeredi
2017-09-14 20:00 ` Linus Torvalds
2017-09-14 20:12 ` Miklos Szeredi
2017-09-14 20:24 ` Linus Torvalds
2017-09-15 7:32 ` Miklos Szeredi
2017-09-15 8:06 ` Miklos Szeredi
2017-09-17 21:27 ` Dave Chinner
2017-09-15 18:35 ` Linus Torvalds
2017-09-17 14:38 ` J. R. Okajima [this message]
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=14181.1505659095@jrobl \
--to=hooanon05g@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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).