From: sashiko-bot@kernel.org
To: "Crystal Wood" <crwood@redhat.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v6 05/10] tracing/osnoise: Per-cpu mutexes and fd detachment
Date: Wed, 28 Oct 2026 22:20:08 +0000 [thread overview]
Message-ID: <sashiko-outbox-188496@kernel.org> (raw)
In-Reply-To: <20261028220120.4005187-6-crwood@redhat.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] tracing/osnoise: unreachable migration handling in timerlat_fd_read()
- [Medium] tracing/osnoise: stale tracing_thread after signal in timerlat_fd_read()
--
commit fc0df59115a148fd84654dadbdbb8ffa3b889971
Author: Crystal Wood <crwood@redhat.com>
tracing/osnoise: Per-cpu mutexes and fd detachment
This patch introduces per-CPU mutexes in osnoise_variables and
timerlat_variables to synchronize kthread lifecycle and file descriptor
open, close, and detachment, replacing the previous SIGKILL mechanism
for user-space timerlat threads.
> diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
> index 791a9103c2ec0..cd386c75926e4 100644
> --- a/kernel/trace/trace_osnoise.c
> +++ b/kernel/trace/trace_osnoise.c
[ ... ]
> @@ -2496,37 +2572,44 @@ static ssize_t
> timerlat_fd_read(struct file *file, char __user *ubuf, size_t count,
> loff_t *ppos)
> {
> - long cpu = (long) file->private_data;
> + struct fd_data *fdd = file->private_data;
> struct osnoise_variables *osn_var;
> struct timerlat_variables *tlat;
> struct timerlat_sample s;
> s64 diff;
> u64 now;
> + int ret = 0;
>
> migrate_disable();
>
> tlat = this_cpu_tmr_var();
> + osn_var = this_cpu_osn_var();
> +
> + /* In normal usage, this should always be uncontended. */
> + mutex_lock(&tlat->detach_lock);
> + if (fdd != osn_var->fdd || current != fdd->thread) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> /*
> * While in user-space, the thread is migratable. There is nothing
> * we can do about it.
> * So, if the thread is running on another CPU, stop the machinery.
> */
> - if (cpu == smp_processor_id()) {
> + if (fdd->cpu == smp_processor_id()) {
> if (tlat->uthread_migrate) {
> - migrate_enable();
> - return -EINVAL;
> + ret = -EINVAL;
> + goto out;
> }
> } else {
> - cpu_tmr_var(cpu)->uthread_migrate = 1;
> + cpu_tmr_var(fdd->cpu)->uthread_migrate = 1;
> osnoise_taint("timerlat user thread migrate\n");
> osnoise_stop_tracing();
> - migrate_enable();
> - return -EINVAL;
> + ret = -EINVAL;
> + goto out;
> }
[Severity: Medium]
In timerlat_fd_open(), fdd is stored only in the osnoise_variables for
fdd->cpu.
In timerlat_fd_read(), osn_var and tlat are fetched via this_cpu_osn_var()
and this_cpu_tmr_var() for smp_processor_id(). If the user-space thread
migrated to another CPU before calling read(), osn_var belongs to the new
CPU, where osn_var->fdd cannot match fdd.
Because fdd != osn_var->fdd is checked before fdd->cpu == smp_processor_id(),
won't a migrated thread always lock the new CPU's detach_lock and bail out
at the fdd != osn_var->fdd check, making the else branch that sets
cpu_tmr_var(fdd->cpu)->uthread_migrate, calls osnoise_taint(), and stops
tracing via osnoise_stop_tracing() unreachable?
> @@ -2561,9 +2644,6 @@ timerlat_fd_read(struct file *file, char __user *ubuf, size_t count,
> }
> }
> } else {
> - tlat->tracing_thread = false;
> - tlat->thread = current;
> -
> /* Annotate now to drift new period */
> tlat->abs_period = hrtimer_cb_get_time(&tlat->timer);
>
> @@ -2571,7 +2651,20 @@ timerlat_fd_read(struct file *file, char __user *ubuf, size_t count,
> }
>
> /* wait for the next period */
> - wait_next_period(tlat);
> + if (wait_next_period(tlat) < 0) {
> + if (signal_pending(current))
> + ret = -ERESTARTSYS;
> + else
> + ret = -EINVAL;
> +
> + osn_var->sampling = false;
> + goto out;
> + }
[Severity: Medium]
If timerlat_irq() fires in hardirq context while the thread is in
wait_next_period(), it sets tlat->tracing_thread = true:
kernel/trace/trace_osnoise.c:timerlat_irq() {
...
/*
* Enable the osnoise: events for thread an softirq.
*/
tlat->tracing_thread = true;
...
}
If a signal is also pending before wait_next_period() checks
signal_pending(current), wait_next_period() returns -1 and timerlat_fd_read()
clears osn_var->sampling = false, but leaves tlat->tracing_thread set to
true.
Since tlat->tracing_thread = false was removed from the !osn_var->sampling
branch above, if the read() is restarted or called again, it sets
osn_var->sampling = 1 with tlat->tracing_thread still true before entering
wait_next_period(). While sleeping for the next timer activation, won't
timerlat_thread_exit() and timerlat_softirq_exit() see both osn_var->sampling
and tlat->tracing_thread as true and emit spurious noise events before the
timer expires?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261028220120.4005187-1-crwood@redhat.com?part=5
next prev parent reply other threads:[~2026-10-28 22:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 22:01 [PATCH v6 0/10] tracing/osnoise: Synchronization fixes Crystal Wood
2026-10-28 22:01 ` [PATCH v6 01/10] tracing/osnoise: Variable cleanup Crystal Wood
2026-10-28 22:01 ` [PATCH v6 02/10] tracing/osnoise: start_kthread: Always check OSN_WORKLOAD Crystal Wood
2026-10-28 22:06 ` sashiko-bot
2026-10-28 22:01 ` [PATCH v6 03/10] tracing/osnoise: Start all eligible cpus from hotplug workfn Crystal Wood
2026-10-28 22:01 ` [PATCH v6 04/10] tracing/osnoise: Hold a ref on osn->kthread Crystal Wood
2026-10-28 22:01 ` [PATCH v6 05/10] tracing/osnoise: Per-cpu mutexes and fd detachment Crystal Wood
2026-10-28 22:20 ` sashiko-bot [this message]
2026-10-28 22:01 ` [PATCH v6 06/10] tracing/osnoise: Split out per-cpu variable resets Crystal Wood
2026-10-28 22:24 ` sashiko-bot
2026-10-28 22:01 ` [PATCH v6 07/10] tracing/osnoise: kthreads: Verify CPU after migrate_disable() Crystal Wood
2026-10-28 22:01 ` [PATCH v6 08/10] tracing/osnoise: Take trace_types_lock in timerlat_fd_open Crystal Wood
2026-10-28 22:01 ` [PATCH v6 09/10] tracing/osnoise: Print taint message for timerlat Crystal Wood
2026-10-28 22:01 ` [PATCH v6 10/10] tracing/osnoise: Refuse timerlat fd open if tracer inactive Crystal Wood
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=sashiko-outbox-188496@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=crwood@redhat.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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