From: Miklos Szeredi <miklos@szeredi.hu>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
Karel Zak <kzak@redhat.com>,
dhowells@redhat.com, linux-kernel@vger.kernel.org,
linux-unionfs@vger.kernel.org
Subject: Re: d_path() and overlay fs
Date: Fri, 20 Mar 2015 17:53:52 +0100 [thread overview]
Message-ID: <20150320165352.GF20913@tucsk> (raw)
In-Reply-To: <20150320162558.GA29656@ZenIV.linux.org.uk>
On Fri, Mar 20, 2015 at 04:25:58PM +0000, Al Viro wrote:
> On Fri, Mar 20, 2015 at 05:01:23PM +0100, Miklos Szeredi wrote:
>
> > But it does take care of the majority of f_path users that actually want the
> > covering path.
>
> Bloody bad idea, IMO. I have no objections against adding _helpers_ from
> that patch (seq_file_path(), etc.), but I really don't like adding that
> second struct path there. And it still doesn't fix the issue with
> LSM, etc., so we'll _still_ need to fix it sane way.
Obviously getting rid of the extra path would be good. But we still have lots
of f_path.dentry in filesystems and we need to start with that.
struct dentry *file_dentry(struct file *) ? Implemented how? Rename f_inode to
f_dentry and reimplement file_inode() based on that.
BTW, since nobody is accessing ->f_covering_path directly except the single
f_covering_path() helper, it would be extremely easy to get rid of it later.
That's why I posted this patch, I think it's simple enough to get it into v4.0
which would fix the majority of cases that people complain about.
The thing could even be made dependent on CONFIG_OVERLAY_FS if the addition
actually increases the footprint of struct file (I haven't checked).
Thanks,
Miklos
next prev parent reply other threads:[~2015-03-20 16:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 13:29 d_path() and overlay fs Karel Zak
2015-03-20 13:31 ` Al Viro
2015-03-20 13:41 ` Josh Boyer
2015-03-20 16:01 ` Miklos Szeredi
2015-03-20 16:25 ` Al Viro
2015-03-20 16:53 ` Miklos Szeredi [this message]
2015-03-20 18:16 ` Miklos Szeredi
2016-01-06 5:26 ` sangeetha Busangari
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=20150320165352.GF20913@tucsk \
--to=miklos@szeredi.hu \
--cc=dhowells@redhat.com \
--cc=jwboyer@fedoraproject.org \
--cc=kzak@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.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 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.