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

On Tue, 2026-09-01 at 15:32 +0200, Tomas Glozar wrote:

On Mon, Aug 24, 2026 at 11:16 PM Crystal Wood [off-list ref] wrote:

quoted

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