Re: [RFC PATCH v2 0/3] disable optimistic spinning for ftrace_lock

[David Laight <david.laight.linux@gmail.com>]

On Wed, 11 Mar 2026 13:07:43 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 11 Mar 2026 21:40:32 +0800
> Yafang Shao <laoar.shao@gmail.com> wrote:
> 
> > > The code needs to drop the ftrace_lock across t_show.    
> > 
> > It's unclear whether we can safely release ftrace_lock within t_show —
> > doing so would probably necessitate a major redesign of the current
> > implementation.  
> 
> The issue isn't t_show, it's the calls between t_start and t_next and
> subsequent t_next calls, which needs to keep a consistent state. t_show
> just happens to be called in between them.
> 
> >   
> > >
> > > Although there is a bigger issue of why on earth the code is reading the
> > > list of filter functions at all - never mind all the time.    
> > 
> > bpftrace reads the complete list of available functions into
> > userspace, then performs matching against the target function to
> > determine if it is traceable.  
> 
> Could it parse it in smaller bits? That is, the lock is held only during an
> individual read system call. If it reads the available_filter_functions
> file via smaller buffers, it would not hold the lock for as long.

But the expensive part is probably looking up the symbol name.
Shorter reads would hand the lock off to the other process, but overall
the lock would still be held for the same length of time.

How does the code work out where to start from for each read system call?
Couldn't you (effectively) do one symbol at a time the same way?

Another option would be to put a 'generation number' on the list of functions
(after all it doesn't change that often).
Then you can release the lock, generate the data, re-acquire the lock and
check the generation number hasn't changed.
If it hasn't changed you can carry on processing the list using the
same pointer.
If the generation number has changed terminate the read and worry about
locating the correct start position for the next read.

	David


> 
> -- Steve
>