Re: [PATCH] tracing/osnoise: Fix OSN_WORKLOAD-related crash

[Crystal Wood <crwood@redhat.com>]

On Wed, 2026-01-14 at 13:35 +0100, Tomas Glozar wrote:
> A kernel panic was observed in the timerlat tracer with the following
> reproducer:
> 
>    #!/bin/bash
>    while true; do
>       rtla timerlat hist -u -d 5s & PID=$!
>       sleep 2
>       echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options
>       rtla timerlat hist -k -d 1s
>    done
> 
> The kernel first displays several WARN traces with the following pattern:
> 
>    WARNING: CPU: 1 PID: 1822 at kernel/trace/trace_osnoise.c:1959 stop_kthread+0xb7/0xc0

The line number doesn't match up for me; is this the first or second
WARN_ON in that function?

> and finally a null pointer reference BUG:
> 
>    BUG: kernel NULL pointer dereference, address: 0000000000000030
>    ...
>    CPU: 1 UID: 0 PID: 2155 Comm: timerlatu/1
>    ...
>    Call Trace:
>      ...
>      ? timerlat_fd_read+0xf2/0x370
>      ? timerlat_fd_read+0xee/0x370
>      vfs_read+0xe8/0x370
>      ksys_read+0x6d/0xf0
>      do_syscall_64+0x7d/0x160
>      ...
>      entry_SYSCALL_64_after_hwframe+0x76/0x7e

What's the actual fault location?  And those ? lines in the call trace
are "considered to be additional clues" rather than actual unwound
frames; what was in the ... above them?

>  static int osnoise_options_open(struct inode *inode, struct file *file)
>  {
>  	return seq_open(file, &osnoise_options_seq_ops);
> @@ -2229,6 +2254,10 @@ static ssize_t osnoise_options_write(struct file *filp, const char __user *ubuf,
>  	if (option < 0)
>  		return -EINVAL;
>  
> +	retval = osnoise_validate_option(option, enable);
> +	if (retval != 0)
> +		return retval;
> +
>  	/*
>  	 * trace_types_lock is taken to avoid concurrency on start/stop.
>  	 */

Shouldn't this be done under interface_lock to avoid concurrent
timerlat_fd_open()?  FWIW, your test script doesn't appear to cover the
case of option setting racing with timerlat starting (due to the 2
second delay).

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.

Though even in the non-race case, we might still want to return -EBUSY
rather than just killing the thread (which might still have races since
we don't wait for the user thread to die).

-Crystal