From: Chris Down <chris@chrisdown.name>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Christian Brauner <brauner@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tejun Heo <tj@kernel.org>, Jori Koolstra <jkoolstra@xs4all.nl>,
Meta kernel team <kernel-team@meta.com>,
linux-fsdevel@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] kernfs: allocate inodes and dentry outside kernfs_rwsem
Date: Thu, 12 Nov 2026 15:02:23 -0800 [thread overview]
Message-ID: <20261112150223.f13e8b526933f9fd@chrisdown.name> (raw)
In-Reply-To: <20261111215058.1837351-1-shakeel.butt@linux.dev>
Hi Shakeel,
Shakeel Butt writes:
>+ new = new_inode(sb);
>+ if (!new)
>+ return ERR_PTR(-ENOMEM);
Not a big deal, but one thing changed from v3 that the changelog doesn't
mention. Without an ilookup() first, every caller now needs the
preallocated inode even when one is already hashed. Before this patch
iget_locked() returned a hashed inode without allocating. So when
new_inode() fails, decoding a handle for a live node whose inode is
cached now fails with -ENOMEM, and a stale handle gets -ENOMEM instead of
-ESTALE. kernfs_iop_lookup() does the same for a node that already has an
inode.
From a quick check I did with failslab limited to inode_cache and an fd
held open on a cgroup2 directory, open_by_handle_at() on its handle
succeeds without this patch and fails with ENOMEM with it.
Now, new_inode() only fails there for an OOM victim, or in a memcg whose
OOM killer is disabled or has nothing left to kill, and those tasks are
failing most other allocations too, so I don't think it's worth
complicating kernfs_get_inode_locked() for. But it is a second case
besides an inactive node where an ilookup() first changes the result.
Not a problem, just an observation, so feel free to add:
Reviewed-by: Chris Down <chris@chrisdown.name>
Thanks!
Chris
prev parent reply other threads:[~2026-11-12 23:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 21:50 Shakeel Butt
2026-11-12 11:38 ` Jori Koolstra
2026-11-12 13:29 ` Shakeel Butt
2026-11-12 14:43 ` Jori Koolstra
2026-11-12 23:02 ` Chris Down [this message]
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=20261112150223.f13e8b526933f9fd@chrisdown.name \
--to=chris@chrisdown.name \
--cc=brauner@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=jkoolstra@xs4all.nl \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=tj@kernel.org \
/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
all inboxes | Powered by JetHome®