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 <zhengyeji...@huawei.com> 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.529842...@goodmis.org/
-- Steve
