Linux block layer
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Huang Shijie <huangsj@hygon.cn>
Cc: axboe@kernel.dk, viro@zeniv.linux.org.uk, brauner@kernel.org,
	jack@suse.cz, zhongyuan@hygon.cn, fangbaoshun@hygon.cn,
	yingzhiwei@hygon.cn, agruenba@redhat.com, mic@digikod.net,
	gnoack@google.com, paul@paul-moore.com, jmorris@namei.org,
	serge@hallyn.com, aleksa@amutable.com, legion@kernel.org,
	david@kernel.org, sandeen@redhat.com, ebiggers@kernel.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, gfs2@lists.linux.dev,
	linux-security-module@vger.kernel.org, sunjunchao@bytedance.com,
	shijie8@gmail.com
Subject: Re: [PATCH v2 1/3] vfs: add inode iteration methods
Date: Fri, 13 Nov 2026 04:23:40 -0800	[thread overview]
Message-ID: <avcBTMvzFWuCkwkn@infradead.org> (raw)
In-Reply-To: <20261113115702.586594-2-huangsj@hygon.cn>

On Fri, Nov 13, 2026 at 07:57:00PM +0800, Huang Shijie wrote:
> +/*
> + * Unsafe iteration for internal VFS use only:
> + *   @ctx->iter_fn runs in atomic context with only
> + *   an inode existence guarantee, so it must not block
> + *   and must perform its own inode state checks.
> + *
> + * Return INO_ITER_RET_ABORT if the iteration stops early.
> + * Return INO_ITER_RET_DONE if the iteration runs to the end.
> + */
> +static inline int super_iter_inodes_unsafe(struct super_block *sb,
> +				struct inode_iter_context *ctx)
> +{
> +	struct inode *inode;
> +	int ret = INO_ITER_RET_NEXT;
> +
> +	rcu_read_lock();
> +	spin_lock(&sb->s_inode_list_lock);
> +	inode = list_prepare_entry(ctx->prev, &sb->s_inodes, i_sb_list);
> +
> +	list_for_each_entry_continue(inode, &sb->s_inodes, i_sb_list) {

This is a really odd way to write a list iteration.  I also don't see
how the RCU lock is needed when you already hold the spinlock.

I honestly don't get this "iterator.  It is trivial, the _unsafe is
wrong naming.  What is the point?

> +/**
> + * super_iter_inodes - iterate all the cached inodes on a superblock
> + * @sb: superblock to iterate
> + * @ctx: the context which has the metadata
> + *
> + * This function iterates all cached inodes on a superblock that are not in
> + * the process of being initialised or torn down. It will run @ctx->iter_fn()
> + * with a valid, referenced inode, so it is safe for the caller to do
> + * anything it wants with the inode except drop the reference the iterator
> + * holds.
> + *
> + * Return INO_ITER_RET_DONE if the iteration runs to the end.
> + * Return other value if the iteration breaks.
> + */
> +int super_iter_inodes(struct super_block *sb, struct inode_iter_context *ctx)

This one makes a lot more sense, but the callback pattern is a bit
annoying as it requires to stuff all information into the context.
Im much of the core kernel we're slowly switching to an iterator
model that allows the caller to keep the state.  In this case something
like

	struct inode_iter_contex ctx = INODE_ITER_CTX_INIT;

	while ((inode = sb_inode_iter()))) {
		/* do stuff */
	}

which should be easily possibly with this model.

You probably also want to split the core iterator and switching each
user into separate patches.

  reply	other threads:[~2026-11-13 12:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 11:56 [PATCH v2 0/3] vfs: add inode iteration methods Huang Shijie
2026-11-13 11:57 ` [PATCH v2 1/3] " Huang Shijie
2026-11-13 12:23   ` Christoph Hellwig [this message]
2026-11-13 11:57 ` [PATCH v2 2/3] vfs: convert inode iterators to super_iter_inodes_unsafe() Huang Shijie
2026-11-13 11:57 ` [PATCH v2 3/3] vfs: convert sb->s_inodes iteration to super_iter_inodes() Huang Shijie

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=avcBTMvzFWuCkwkn@infradead.org \
    --to=hch@infradead.org \
    --cc=agruenba@redhat.com \
    --cc=aleksa@amutable.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=fangbaoshun@hygon.cn \
    --cc=gfs2@lists.linux.dev \
    --cc=gnoack@google.com \
    --cc=huangsj@hygon.cn \
    --cc=jack@suse.cz \
    --cc=jmorris@namei.org \
    --cc=legion@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=sandeen@redhat.com \
    --cc=serge@hallyn.com \
    --cc=shijie8@gmail.com \
    --cc=sunjunchao@bytedance.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yingzhiwei@hygon.cn \
    --cc=zhongyuan@hygon.cn \
    /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