Re: [RFC PATCH] trace: Introduce a new filter_pred "caller"

["chenjun (AM)" <chenjun102@huawei.com>]

在 2026/5/29 22:38, Steven Rostedt 写道:
> 
> Hi Chen,
> 
> Do you plan on sending updates to address the comments that Masami and
> I have made?
> 
> -- Steve

Hi，

Sorry, I've been busy with other things lately. I'll release the patch 
v2 next week.

One thing I'd like to confirm is whether to use `called_within` as the 
filter name.

Thanks
-- Chen Jun

> 
> 
> On Thu, 14 May 2026 13:19:01 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> 
>> On Wed, 13 May 2026 12:40:17 -0400
>> Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>>> On Tue, 12 May 2026 08:47:50 +0900
>>> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>>>    
>>>> On Fri, 8 May 2026 20:26:23 +0800
>>>> Chen Jun <chenjun102@huawei.com> wrote:
>>>>    
>>>>> Low-level functions have many call paths, and sometimes
>>>>> we only care about the calls on a specific call path.
>>>>> Add a new filter to filter based on the call stack.
>>>>>
>>>>> Usage:
>>>>> 1. echo 'caller=="$function_name"' > events/../filter
>>>>
>>>> Thanks for interesting idea :)
>>>>
>>>> BTW, we already have "stacktrace". Since this actually checks
>>>> stacktrace, not caller, so I think we should reuse it.
>>>> Also, I think OP_GLOB is more suitable for this case.
>>>> (and more useful)
>>>
>>> Actually, it's not a stack trace, it's a function that is called from other
>>> functions. But since "caller" sounds like a direct called function (stack
>>> trace of the first instance), I think perhaps it should be "called_within" or
>>> something similar. :-/
>>
>> Yeah, what about "callers"?
>>
>>>
>>> Also, OP_GLOB can't work because it only works for a single function. At
>>> the time of parsing, it finds the function (and should probably error out
>>> if there's more than one function with a given name). It then records the
>>> start and end address of the function so it only needs to find if one of
>>> the entries in the stack trace is between the start and end of the function.
>>
>> Ah, OK. It is just comparing address, not name.
>>
>>>
>>> I don't think this is possible with GLOB. We don't want to do a search of
>>> the functions when the event is triggered.
>>
>> Agreed.
>>
>> Thanks,
>>
>>>
>>> -- Steve
>>
>>
> 
> 
>