[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220714224646.62d49e36@rorschach.local.home>
Date: Thu, 14 Jul 2022 22:46:46 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Song Liu <songliubraving@...com>
Cc: Song Liu <song@...nel.org>, Networking <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Kernel Team <Kernel-team@...com>,
"jolsa@...nel.org" <jolsa@...nel.org>,
"mhiramat@...nel.org" <mhiramat@...nel.org>
Subject: Re: [PATCH v2 bpf-next 3/5] ftrace: introduce
FTRACE_OPS_FL_SHARE_IPMODIFY
On Fri, 15 Jul 2022 02:04:33 +0000
Song Liu <songliubraving@...com> wrote:
> > What I'm suggesting is that a DIRECT ops will never set IPMODIFY.
>
> Aha, this the point I misunderstood. I thought DIRECT ops would always
> set IPMODIFY (as it does now).
My fault. I was probably not being clear when I was suggesting that
DIRECT should *act* like an IPMODIFY, but never explicitly stated that
it should not set the IPMODIFY flag.
The only reason it does today was to make it easy to act like an
IPMODIFY (because it set the flag). But I'm now suggesting to get rid
of that and just make DIRECT act like an IPMDOFIY as there can only be
one of them on a function, but now we have some cases where DIRECT can
work with IPMODIFY via the callbacks.
-- Steve
Powered by blists - more mailing lists