On Thu, 15 Jan 2026 14:32:27 +0100
Tomas Glozar <[email protected]> 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
