On 2025/1/22 01:48, Steven Rostedt wrote:

Sorry for the late reply. Forgot about this as I was focused on other end-of-year issues.

On Sat, 14 Dec 2024 16:37:59 +0800
Zheng Yejian [off-list ref] wrote:

quoted

The direct cause of this issue is the wrong fentry being founded by ftrace_location(),
following the approach of "FTRACE_MCOUNT_MAX_OFFSET", narrowing down the search range
and re-finding may also solve this problem, demo patch like below (not
fully tested):

      diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
      index 9b17efb1a87d..7d34320ca9d1 100644
      --- a/kernel/trace/ftrace.c
      +++ b/kernel/trace/ftrace.c
      @@ -1678,8 +1678,11 @@ unsigned long ftrace_location(unsigned long ip)
                              goto out;
      
                      /* map sym+0 to __fentry__ */
      -               if (!offset)
      +               if (!offset) {
                              loc = ftrace_location_range(ip, ip + size - 1);
      +                       while (loc > ip && loc - ip > FTRACE_MCOUNT_MAX_OFFSET)
      +                               loc = ftrace_location_range(ip, loc - 1);
      +               }
              }

Steve, Peter, what do you think?

Hmm, removing the weak functions from the __mcount_loc location should also
solve this, as the ftrace_location_range() will not return a weak function
if it's not part of the __mcount_loc table.

That is, would this patchset work?

   https://lore.kernel.org/all/20250102232609.529842248@goodmis.org/ (local)

I only pick patch15 and patch16 into v6.14-rc1, since most of patches in that patches
have already merged, and the issue seems gone, thanks!

-- Steve

-- 
Thanks,
Zheng Yejian