From: Kevin Mitchell <kevmitch@arista.com>
To: Tejun Heo <tj@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kevin Mitchell <kevmitch@arista.com>,
stable@vger.kernel.org,
Chengming Zhou <zhouchengming@bytedance.com>,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH v3] kernfs: fix race to increment for nr_mmapped in kernfs_fop_mmap()
Date: Fri, 31 Jul 2026 12:08:50 -0700 [thread overview]
Message-ID: <20260731190850.235909-2-kevmitch@arista.com> (raw)
Counts of files to be released (nr_to_release) and mmapped (nr_mmapped)
files were added to kernfs_open_node in commit bdb2fd7fc56e ("kernfs:
Skip kernfs_drain_open_files() more aggressively") to optimize
kernfs_drain_open_files(). A WARN_ON_ONCE sanity check was also added in
kernfs_drain_open_files() to ensure that these counters were brought to
zero once all files had been drained.
Modifications to these counters were protected by kernfs_open_file_mutex
everywhere except for in kernfs_fop_mmap(). This caused a race condition
where some nr_mmapped increments could get overwritten even while the
correct number of kernfs_open_files with mmapped == true were present in
the kernfs_open_node's files list. Consequently, the iteration in
kernfs_drain_open_files() would underflow nr_mmapped and the WARNING
would fire.
To fix this, acquire kernfs_open_file_mutex around nr_mmapped updates in
kernfs_fop_mmap.
The nesting of->mutex -> kernfs_open_file_mutex is safe as
kernfs_open_file_mutex is acquired last avoiding the possible cycles
highlighted in commit f83f3c515654 ("kernfs: fix locking around
kernfs_ops->release() callback").
Fixes: bdb2fd7fc56e ("kernfs: Skip kernfs_drain_open_files() more aggressively")
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
---
Changes in v3:
- Remove stray linebreak and cc stable.
- Link to v1: https://lore.kernel.org/all/20251119191758.612694-2-kevmitch@arista.com
- Link to v2: https://lore.kernel.org/all/20260731010914.233067-2-kevmitch@arista.com
fs/kernfs/file.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 8e0e90c93372..76ade0d0be04 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -495,8 +495,11 @@ static int kernfs_fop_mmap(struct file *file, struct vm_area_struct *vma)
rc = 0;
if (!of->mmapped) {
- of->mmapped = true;
+ struct mutex *mutex = kernfs_open_file_mutex_lock(of->kn);
+
of_on(of)->nr_mmapped++;
+ mutex_unlock(mutex);
+ of->mmapped = true;
of->vm_ops = vma->vm_ops;
}
vma->vm_ops = &kernfs_vm_ops;
--
2.51.0
reply other threads:[~2026-07-31 19:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260731190850.235909-2-kevmitch@arista.com \
--to=kevmitch@arista.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=zhouchengming@bytedance.com \
/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