On Wed, 11 Mar 2026 21:40:32 +0800 Yafang Shao <[email protected]> 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. -- Steve
