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 <zhengyejian1@xxxxxxxxxx> wrote: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@xxxxxxxxxxx/
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
