Thread (15 messages) flat view 15 messages, 4 authors, 4d ago

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

From: Tomas Glozar <tglozar@redhat.com>
Date: 2026-09-01 13:32:56

On Mon, Aug 24, 2026 at 11:16 PM Crystal Wood [off-list ref] 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 a
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?
Signed-off-by: Crystal Wood <redacted>
---
 kernel/trace/trace_osnoise.c | 239 +++++++++++++++++++++--------------
 1 file changed, 144 insertions(+), 95 deletions(-)

[truncated]
Tomas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help