linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org
Subject: Re: [PATCH v3 1/2] fs: use fake_file container for internal files with fake f_path
Date: Sun, 11 Jun 2023 21:45:45 -0700	[thread overview]
Message-ID: <ZIai+UWrU9o2UVcJ@infradead.org> (raw)
In-Reply-To: <20230611194706.1583818-2-amir73il@gmail.com>

On Sun, Jun 11, 2023 at 10:47:05PM +0300, Amir Goldstein wrote:
> Overlayfs and cachefiles use open_with_fake_path() to allocate internal
> files, where overlayfs also puts a "fake" path in f_path - a path which
> is not on the same fs as f_inode.

But cachefs doesn't, so this needs a better explanation / documentation.

> Allocate a container struct file_fake for those internal files, that
> is used to hold the fake path along with an optional real path.

The idea looks sensible, but fake a is a really weird term here.
I know open_with_fake_path also uses it, but we really need to
come up with a better name, and also good documentation of the
concept here.

> +/* Returns the real_path field that could be empty */
> +struct path *__f_real_path(struct file *f)
> +{
> +	struct file_fake *ff = file_fake(f);
> +
> +	if (f->f_mode & FMODE_FAKE_PATH)
> +		return &ff->real_path;
> +	else
> +		return &f->f_path;
> +}

two of the three callers always have FMODE_FAKE_PATH set, so please
just drop this helper and open code it in the three callers.

> +
> +/* Returns the real_path if not empty or f_path */
> +const struct path *f_real_path(struct file *f)
> +{
> +	const struct path *path = __f_real_path(f);
> +
> +	return path->dentry ? path : &f->f_path;
> +}
> +EXPORT_SYMBOL(f_real_path);

This is only needed by the few places like nfsd or btrfs send
that directlycall fsnotify and should at very least be
EXPORT_SYMBOL_GPL.  But I suspect with all the exta code, fsnotify_file
really should move out of line and have an EXORT_SYMBOL_GPL instead.

> +
> +const struct path *f_fake_path(struct file *f)
> +{
> +	return &f->f_path;
> +}
> +EXPORT_SYMBOL(f_fake_path);

.. and this helper is completely pointless.

> +extern struct file *alloc_empty_file(int flags, const struct cred *cred);
> +extern struct file *alloc_empty_file_fake(int flags, const struct cred *cred);
> +extern struct path *__f_real_path(struct file *f);

Please drop all the pointless externs while you're at it.

  reply	other threads:[~2023-06-12  4:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-11 19:47 [PATCH v3 0/2] Handle notifications on overlayfs fake path files Amir Goldstein
2023-06-11 19:47 ` [PATCH v3 1/2] fs: use fake_file container for internal files with fake f_path Amir Goldstein
2023-06-12  4:45   ` Christoph Hellwig [this message]
2023-06-12  6:37     ` Amir Goldstein
2023-06-12  8:01       ` Christian Brauner
2023-06-12  8:07     ` Christian Brauner
2023-06-12  8:28       ` Amir Goldstein
2023-06-12  8:31         ` Christian Brauner
2023-06-11 19:47 ` [PATCH v3 2/2] ovl: enable fsnotify events on underlying real files Amir Goldstein
2023-06-12 15:18 ` [PATCH v3 0/2] Handle notifications on overlayfs fake path files Amir Goldstein

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=ZIai+UWrU9o2UVcJ@infradead.org \
    --to=hch@infradead.org \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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).