All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Crystal Wood" <crwood@redhat.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v7 05/10] tracing/osnoise: Per-cpu mutexes and fd detachment
Date: Fri, 13 Nov 2026 07:14:53 +0000	[thread overview]
Message-ID: <sashiko-outbox-212329@kernel.org> (raw)
In-Reply-To: <20261113064103.3041704-6-crwood@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] tracing/osnoise: missing migration detection in
  timerlat_fd_read()
--

commit d34bc9208d90b4be9c903307f53e72248c2ac3b7
Author: Crystal Wood <crwood@redhat.com>

tracing/osnoise: Per-cpu mutexes and fd detachment

This commit introduces per-cpu mutexes to protect kthread and timerlat file
descriptor state, replacing the SIGKILL mechanism for user-space timerlat
threads with a mutex-protected detachment mechanism.

[Severity: Medium]
In kernel/trace/trace_osnoise.c, timerlat_fd_read() removes the
cpu != smp_processor_id() migration handling (which set
cpu_tmr_var(cpu)->uthread_migrate = 1, tainted osnoise, and stopped
tracing) and instead locks this_cpu_tmr_var()->detach_lock before checking
fdd != osn_var->fdd or tlat->uthread_migrate.

Can this miss user-space thread migrations when NO_OSNOISE_WORKLOAD is
enabled after the timerlat tracer has already been started?

By default, OSN_WORKLOAD is set in osnoise_options. If the user enables
timerlat first and then writes NO_OSNOISE_WORKLOAD to osnoise/options (as
shown in Documentation/trace/timerlat-tracer.rst), osnoise_options_write()
does not call register_migration_monitor(), which only runs during initial
tracer startup in osnoise_workload_start() -> osnoise_hook_events() ->
hook_thread_events() -> register_migration_monitor() and skips registering
trace_sched_migrate_callback() when OSN_WORKLOAD is set.

Without trace_sched_migrate_callback() registered and with the migration
handling removed from timerlat_fd_read(), a thread that migrates to
another CPU and calls timerlat_fd_read() acquires the destination CPU's
tlat->detach_lock rather than fdd->cpu's lock, never sets
cpu_tmr_var(fdd->cpu)->uthread_migrate, and does not taint or stop
tracing; if the thread later migrates back to fdd->cpu, subsequent reads
continue succeeding instead of failing with -EINVAL.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113064103.3041704-1-crwood@redhat.com?part=5

  reply	other threads:[~2026-11-13  7:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13  6:40 [PATCH v7 00/10] tracing/osnoise: Synchronization fixes Crystal Wood
2026-11-13  6:40 ` [PATCH v7 01/10] tracing/osnoise: Variable cleanup Crystal Wood
2026-11-13  6:40 ` [PATCH v7 02/10] tracing/osnoise: start_kthread: Always check OSN_WORKLOAD Crystal Wood
2026-11-13  6:40 ` [PATCH v7 03/10] tracing/osnoise: Start all eligible cpus from hotplug workfn Crystal Wood
2026-11-13  6:51   ` sashiko-bot
2026-11-13  6:40 ` [PATCH v7 04/10] tracing/osnoise: Hold a ref on osn->kthread Crystal Wood
2026-11-13  6:40 ` [PATCH v7 05/10] tracing/osnoise: Per-cpu mutexes and fd detachment Crystal Wood
2026-11-13  7:14   ` sashiko-bot [this message]
2026-11-13  6:40 ` [PATCH v7 06/10] tracing/osnoise: Reset cleanup Crystal Wood
2026-11-13  7:20   ` sashiko-bot
2026-11-13  6:41 ` [PATCH v7 07/10] tracing/osnoise: kthreads: Verify CPU after migrate_disable() Crystal Wood
2026-11-13  6:41 ` [PATCH v7 08/10] tracing/osnoise: Take trace_types_lock in timerlat_fd_open Crystal Wood
2026-11-13  6:41 ` [PATCH v7 09/10] tracing/osnoise: Print taint message for timerlat Crystal Wood
2026-11-13  6:41 ` [PATCH v7 10/10] tracing/osnoise: Refuse timerlat fd open if tracer inactive Crystal Wood
2026-11-13  6:55   ` 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=sashiko-outbox-212329@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 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.