From: Gao Xiang <xiang@kernel.org>
To: Giuseppe Scrivano <gscrivan@redhat.com>
Cc: linux-erofs@lists.ozlabs.org, xiang@kernel.org,
linux-fsdevel@vger.kernel.org, amir73il@gmail.com,
brauner@kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v5 1/2] fs: rename vfs_get_super() to get_tree_super() and export it
Date: Tue, 11 Aug 2026 23:44:20 +0800 [thread overview]
Message-ID: <antDVPzz0tbn2kTU@XiangdeMacBook-Pro.local> (raw)
In-Reply-To: <20260811071241.389589-2-gscrivan@redhat.com>
(+ cc vfs maintainers)
Hi,
On Tue, Aug 11, 2026 at 09:10:50AM +0200, Giuseppe Scrivano wrote:
> vfs_get_super() already implements the common get_tree pattern of
> looking up an existing superblock via a test callback and initialising
> a new one with fill_super otherwise, but it is private to fs/super.c
> and only reachable through the get_tree_nodev()/get_tree_single()/
> get_tree_keyed() wrappers, none of which let a filesystem supply its
> own test callback.
>
> Rename it to get_tree_super() and export it so filesystems that need a
> custom superblock matching policy can reuse it directly instead of
> open-coding sget_fc() + fill_super(). No functional change.
>
> This is a preparatory fix for the next patch.
>
> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
With the new vfs_get_super() helper, it seems much cleaner compared
to the previous versions.
Since this series interacts with the other erofs ongoing patches.
So I hope at least [PATCH 2/2] can be routed into the erofs tree to
avoid unnecessary conflict resolving.
Maybe the simplistic way is vfs maintainers can ack this vfs patch so
that both patches can go through erofs tree for the next cycle
directly.
> ---
...
> +/**
> + * get_tree_super - Get a superblock, optionally sharing an existing one
> + * @fc: The filesystem context holding the parameters
> + * @test: Comparison function to find a matching existing superblock, or NULL
> + * @fill_super: Helper to initialise a new superblock
> + *
> + * If @test is non-NULL and matches an existing superblock, that superblock is
> + * reused; otherwise a new anonymous superblock is created and initialised with
> + * @fill_super. Passing NULL for @test always creates a new superblock.
> + */
> +int get_tree_super(struct fs_context *fc,
> int (*test)(struct super_block *, struct fs_context *),
> int (*fill_super)(struct super_block *sb,
> struct fs_context *fc))
> @@ -1278,12 +1288,13 @@ static int vfs_get_super(struct fs_context *fc,
> deactivate_locked_super(sb);
> return err;
> }
> +EXPORT_SYMBOL(get_tree_super);
btw, some people prefer EXPORT_SYMBOL_GPL() for this kind of helpers.
Thanks,
Gao Xiang
next prev parent reply other threads:[~2026-08-11 15:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 7:10 [PATCH v5 0/2] erofs: share the superblock for file-backed mounts Giuseppe Scrivano
2026-08-11 7:10 ` [PATCH v5 1/2] fs: rename vfs_get_super() to get_tree_super() and export it Giuseppe Scrivano
2026-08-11 15:44 ` Gao Xiang [this message]
2026-08-11 15:59 ` Giuseppe Scrivano
2026-08-11 7:10 ` [PATCH v5 2/2] erofs: reuse superblock for file-backed mounts Giuseppe Scrivano
2026-08-11 15:31 ` Gao Xiang
2026-08-11 15:57 ` Giuseppe Scrivano
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=antDVPzz0tbn2kTU@XiangdeMacBook-Pro.local \
--to=xiang@kernel.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=gscrivan@redhat.com \
--cc=jack@suse.cz \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@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.