All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Tomas Glozar <tglozar@redhat.com>
Cc: Crystal Wood <crwood@redhat.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	John Kacur <jkacur@redhat.com>,
	Luis Goncalves <lgoncalv@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing/osnoise: Fix OSN_WORKLOAD-related crash
Date: Thu, 15 Jan 2026 10:52:37 -0500	[thread overview]
Message-ID: <20260115105237.3788e1be@fedora> (raw)
In-Reply-To: <CAP4=nvQeBnAtbQFjAdKhQUP1_Xi2uEH0i+kZC6TZwu7GZJYu3w@mail.gmail.com>

On Thu, 15 Jan 2026 14:32:27 +0100
Tomas Glozar <tglozar@redhat.com> wrote:

> > Of course, this is complicated by stop_per_cpu_kthreads() happening
> > before interface_lock is acquired.  Do we know why that happens outside
> > the lock?  That might even be the actual cause of this bug.  
> 
> Before commit b484a02c9c ("tracing/timerlat: Drop interface_lock in
> stop_kthread()"), stop_kthread() took interface_lock, so
> stop_per_cpu_kthreads() couldn't be called while holding
> interface_lock. As that is no longer the case, the position of taking
> interface_lock in osnoise_options_write() could be re-evaluated
> (comment in 5bfbcd1ee57b says interface_lock cannot be taken at the
> same time as cpu_read_lock).

Right. Also take a look at commit 177e1cc2f4123 ("tracing/osnoise: Use
a cpumask to know what threads are kthreads"). I don't remember the
details but there was a lot of issues with lock ordering between the
interface_lock and the cpu_read_lock. Whatever changes you make, make
sure to run lockdep while doing your tests.

-- Steve

      reply	other threads:[~2026-01-15 15:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14 12:35 [PATCH] tracing/osnoise: Fix OSN_WORKLOAD-related crash Tomas Glozar
2026-01-14 19:49 ` Crystal Wood
2026-01-15 13:32   ` Tomas Glozar
2026-01-15 15:52     ` Steven Rostedt [this message]

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=20260115105237.3788e1be@fedora \
    --to=rostedt@goodmis.org \
    --cc=crwood@redhat.com \
    --cc=jkacur@redhat.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.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.