From: Crystal Wood <crwood@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Tomas Glozar <tglozar@redhat.com>, John Kacur <jkacur@redhat.com>,
linux-trace-kernel@vger.kernel.org,
Crystal Wood <crwood@redhat.com>
Subject: [PATCH 4/4] tracing/osnoise: Take trace_types_lock in timerlat_fd_open
Date: Mon, 24 Aug 2026 16:15:44 -0500 [thread overview]
Message-ID: <20260824211544.3984835-5-crwood@redhat.com> (raw)
In-Reply-To: <20260824211544.3984835-1-crwood@redhat.com>
This prevents a user fd from being opened when osnoise_options_write()
has already stopped threads but not yet set OSN_WORKLOAD, and matches what
all callers of start_kthread() do.
The original intent was probably for interface_lock to cover things like
this, but it never covered the full race window, and currently can't
due to lock order issues stemming from using interface_lock in
osnoise_sleep(). There does not appear to be any remaining reason
to take interface_lock in timerlat_fd_open(), so remove it.
Signed-off-by: Crystal Wood <crwood@redhat.com>
---
Do we really need that interface_lock in osnoise_sleep()? Technically
we should probably be grabbing it every time we access osnoise_data, but
we don't seem to do so anywhere else. Perhaps this was due to concerns
about the atomicity of "period - runtime", but that's just synchronization
theater given that userspace has no way of writing to both atomically.
In any case, we shouldn't use the same lock for protecting osnoise_data
members that we use for major reconfiguration procedures.
---
kernel/trace/trace_osnoise.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
index 0f27af6ade3e..3d12ce8a591e 100644
--- a/kernel/trace/trace_osnoise.c
+++ b/kernel/trace/trace_osnoise.c
@@ -2466,16 +2466,14 @@ static int timerlat_fd_open(struct inode *inode, struct file *file)
long cpu = (long) inode->i_cdev;
int ret = 0;
- mutex_lock(&interface_lock);
+ guard(mutex)(&trace_types_lock);
/*
* This file is accessible only if timerlat is enabled, and
* NO_OSNOISE_WORKLOAD is set.
*/
- if (!timerlat_enabled() || test_bit(OSN_WORKLOAD, &osnoise_options)) {
- mutex_unlock(&interface_lock);
+ if (!timerlat_enabled() || test_bit(OSN_WORKLOAD, &osnoise_options))
return -EINVAL;
- }
migrate_disable();
@@ -2524,7 +2522,6 @@ static int timerlat_fd_open(struct inode *inode, struct file *file)
* Setup is done.
*/
mutex_unlock(&osn_var->lock);
- mutex_unlock(&interface_lock);
tlat = this_cpu_tmr_var();
tlat->count = 0;
@@ -2536,7 +2533,6 @@ static int timerlat_fd_open(struct inode *inode, struct file *file)
err:
mutex_unlock(&osn_var->lock);
- mutex_unlock(&interface_lock);
migrate_enable();
return ret;
};
--
2.54.0
next prev parent reply other threads:[~2026-08-24 21:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 21:15 [PATCH 0/4] tracing/osnoise: Synchronization fixes Crystal Wood
2026-08-24 21:15 ` [PATCH 1/4] tracing/osnoise: Per-cpu mutex and fd detachment Crystal Wood
2026-08-24 21:30 ` sashiko-bot
2026-08-26 19:31 ` Steven Rostedt
2026-08-26 21:19 ` Crystal Wood
2026-08-27 0:41 ` Steven Rostedt
2026-08-27 9:04 ` Tomas Glozar
2026-08-26 22:34 ` Crystal Wood
2026-09-01 13:32 ` Tomas Glozar
2026-09-01 16:49 ` Crystal Wood
2026-08-24 21:15 ` [PATCH 2/4] tracing/osnoise: timerlat_main: Disable migration before per-cpu access Crystal Wood
2026-08-24 21:29 ` sashiko-bot
2026-08-24 21:15 ` [PATCH 3/4] tracing/osnoise: start_kthread: Always check OSN_WORKLOAD Crystal Wood
2026-08-24 21:15 ` Crystal Wood [this message]
2026-08-24 21:24 ` [PATCH 4/4] tracing/osnoise: Take trace_types_lock in timerlat_fd_open sashiko-bot
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=20260824211544.3984835-5-crwood@redhat.com \
--to=crwood@redhat.com \
--cc=jkacur@redhat.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglozar@redhat.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 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.