[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <170BE89A-101C-4B25-A664-5E47A902DB83@fb.com>
Date: Fri, 15 Jul 2022 02:50:07 +0000
From: Song Liu <songliubraving@...com>
To: Steven Rostedt <rostedt@...dmis.org>
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 Jul 14, 2022, at 7:46 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 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.
Thanks for the clarification. I think we are finally on the same page on
this. :)
Song
Powered by blists - more mailing lists