Re: [PATCH 1/4] tracing/osnoise: Per-cpu mutex and fd detachment

[Crystal Wood <crwood@redhat.com>]

On Tue, 2026-09-01 at 15:32 +0200, Tomas Glozar wrote:
> On Mon, Aug 24, 2026 at 11:16 PM Crystal Wood <crwood@redhat.com> wrote:
> > 
> > Clean up a variety of synchronization issues and related bandaids
> > by having a per-cpu mutex that guards changes to kthread, and
> > fd open/close/revoke.
> > 
> > Replace the SIGKILL hack for userspace timerlat threads (that doesn't
> > even work, because we don't wait for the process to actually die) with
> > a mutex-protected detachment mechanism.  The mutex should be uncontended
> > during normal timerlat_fd_read() usage.
> > 
> 
> I agree with detaching the file descriptor, that seems to be the right
> pattern. An alternative would be to make the user process to block the
> tracer until it detaches, but that would make it less consistent with
> kernel thread mode - which owns (creates/stops) the threads - as well
> to make it more prone to locking issues during user process exit.
> 
> Can we perhaps clean up the synchronization issues without using a0
> mutex? If one thread is switching timerlat between no thread, user
> thread, and kernel thread, it could mark the osn percpu structure
> "busy" and reject all other switching operations until it is finished.
> As you say, the resource should be uncontended during normal usage, so
> the user shouldn't care about being returned an error instead of
> waiting. Or am I missing something?

The issue is waiting for the completion of an fd operation that has
already passed the "busy" check.  Maybe something custom could be done,
but a mutex seemed simplest at the time.

That said, there is another issue with this patch in its current state,
in that you need to wait for the timer to wake the timerlat thread in
order to get the mutex to detach (and maybe longer depending on mutex
fairness issues).  So it could take a long time if the user sets a long
period.

I've also recently seen some additional issues that I'm in the process
of debugging.

-Crystal