From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
dhowells@redhat.com, Goldwyn Rodrigues <rgoldwyn@suse.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
stable@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Daniel Axtens <dja@axtens.net>
Subject: Re: [PATCH 1/4] vfs: add file_dentry()
Date: Mon, 21 Mar 2016 05:28:09 +0000 [thread overview]
Message-ID: <20160321052808.GH17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1458205323-25685-1-git-send-email-miklos@szeredi.hu>
On Thu, Mar 17, 2016 at 10:02:00AM +0100, Miklos Szeredi wrote:
> Add a new helper, file_dentry() [*], to get the filesystem's own dentry
> from the file. This simply compares file_inode(file->f_path.dentry) to
> file_inode(file) and if they are equal returns file->f_path.dentry (this is
> the common, non-overlayfs case).
>
> In the uncommon case (regular file on overlayfs) it will call into
> overlayfs's ->d_native_dentry() to get the underlying dentry matching
> file_inode(file).
What's wrong with making ovl_dentry_real() an instance of optional
->d_real() method and having a flag (DCACHE_OP_REAL) controlling its
calls? With d_real(dentry) returning either that or dentry itself,
and file_dentry(file) being simply d_real(file->f_path.dentry)...
Why do we need to look at the inode at all? d_set_d_op() dereferences
->d_op anyway, as well as setting ->d_flags, so there's no extra cost
there, and "test bit in ->d_flags + branch not taken" is all it would
cost in normal case...
next prev parent reply other threads:[~2016-03-21 5:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-17 9:02 [PATCH 1/4] vfs: add file_dentry() Miklos Szeredi
2016-03-17 9:02 ` [PATCH 2/4] nfs: use file_dentry() Miklos Szeredi
2016-03-17 9:02 ` [PATCH 3/4] ext4: use dget_parent() in ext4_file_open() Miklos Szeredi
2016-03-17 9:02 ` [PATCH 4/4] ext4: use file_dentry() Miklos Szeredi
2016-03-17 9:09 ` [PATCH 1/4] vfs: add file_dentry() Sedat Dilek
2016-03-17 9:33 ` Miklos Szeredi
2016-03-17 10:15 ` Sedat Dilek
2016-03-17 10:19 ` Sedat Dilek
2016-03-17 14:18 ` Theodore Ts'o
2016-03-21 5:02 ` Theodore Ts'o
2016-03-21 5:22 ` Al Viro
2016-03-22 6:24 ` Daniel Axtens
2016-03-21 5:28 ` Al Viro [this message]
2016-03-21 8:16 ` Miklos Szeredi
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=20160321052808.GH17997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dhowells@redhat.com \
--cc=dja@axtens.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rgoldwyn@suse.com \
--cc=stable@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.