From: Shakeel Butt <shakeel.butt@linux.dev>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tejun Heo <tj@kernel.org>,
Christian Brauner <christian@brauner.io>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Meta kernel team <kernel-team@meta.com>,
linux-fsdevel@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] kernfs: do less work under the kernfs_rwsem write lock
Date: Sat, 12 Sep 2026 19:14:50 -0700 [thread overview]
Message-ID: <20260913021453.21507-1-shakeel.butt@linux.dev> (raw)
kernfs_rwsem is per kernfs root, so sysfs and cgroupfs have one each for
the whole machine, and every create, remove and rename takes it for
writing. Whatever a writer does while holding it, everyone else waits
for. These three patches take work out of that section.
Patch 1: kernfs_add_one() links the node in, drops the lock, then calls
kernfs_activate(), which takes it again. sysfs does not create nodes
deactivated, so it pays two write locks for every file and directory.
Activate before dropping the lock. lock_stat says 1200 -> 830 write
acquisitions for creating and destroying five dummy netdevs.
Patch 2: kernfs_rename_ns() calls kstrdup_const() under the lock. It is
the only GFP_KERNEL allocation under the write lock in kernfs, so a
rename can enter reclaim with the lock held. Allocate before the lock.
Patch 3: kernfs_rename_ns() also frees the old name under the lock with
kfree_rcu_mightsleep(). When its batching allocation fails, which is
what happens under memory pressure, it falls back to synchronize_rcu().
A rename can then wait out a grace period with the lock held. Free
after the unlock.
Tested with the kernfs selftests under KASAN and lockdep.
Shakeel Butt (3):
kernfs: activate a new node without dropping kernfs_rwsem
kernfs: allocate the new name outside kernfs_rwsem
kernfs: free the old name outside kernfs_rwsem
fs/kernfs/dir.c | 32 ++++++++++++++++++++++++++------
1 file changed, 26 insertions(+), 6 deletions(-)
base-commit: 7f24d0f60b1087dbc28d68398957c18774e5a7d8
--
2.53.0-Meta
next reply other threads:[~2026-09-13 2:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 2:14 Shakeel Butt [this message]
2026-09-13 2:14 ` [PATCH 1/3] kernfs: activate a new node without dropping kernfs_rwsem Shakeel Butt
2026-09-13 2:14 ` [PATCH 2/3] kernfs: allocate the new name outside kernfs_rwsem Shakeel Butt
2026-09-13 2:14 ` [PATCH 3/3] kernfs: free the old " Shakeel Butt
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=20260913021453.21507-1-shakeel.butt@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=bigeasy@linutronix.de \
--cc=christian@brauner.io \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.