On Mon, Aug 24, 2026 at 11:16 PM Crystal Wood <[email protected]> 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 <[email protected]> > --- > kernel/trace/trace_osnoise.c | 239 +++++++++++++++++++++-------------- > 1 file changed, 144 insertions(+), 95 deletions(-) > > [truncated] Tomas
