[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251118085156.5a571add@gandalf.local.home>
Date: Tue, 18 Nov 2025 08:51:56 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: bot+bpf-ci@...nel.org
Cc: menglong8.dong@...il.com, ast@...nel.org, daniel@...earbox.net,
john.fastabend@...il.com, andrii@...nel.org, martin.lau@...ux.dev,
eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev,
kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
mhiramat@...nel.org, mark.rutland@....com, mathieu.desnoyers@...icios.com,
jiang.biao@...ux.dev, bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, martin.lau@...nel.org, clm@...a.com,
ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v3 1/6] ftrace: introduce FTRACE_OPS_FL_JMP
On Tue, 18 Nov 2025 13:25:04 +0000 (UTC)
bot+bpf-ci@...nel.org wrote:
> The commit message says "we can tell if we should use 'jmp' for the
> callback in ftrace_call_replace()", but no architecture code is updated
> to check the LSB. Should ftrace_find_rec_direct() and call_direct_funcs()
> mask the JMP bit before returning addresses to architecture code?
I guess AI isn't smart enough to know about kernel config options yet.
> +config DYNAMIC_FTRACE_WITH_JMP
> + def_bool y
> + depends on DYNAMIC_FTRACE
> + depends on DYNAMIC_FTRACE_WITH_DIRECT_CALLS
> + depends on HAVE_DYNAMIC_FTRACE_WITH_JMP
Where this code is only implemented when HAVE_DYNAMIC_FTRACE_WITH_JMP is
set.
-- Steve
Powered by blists - more mailing lists