linux-kernel - Re: [RESEND PATCH bpf-next v4 1/2] bpf, sockmap: Introduce tracing capability for sockmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKK87UV9rH_YviePfUmOO3mGXQmYfN-Q9Ax5AYv+xE8zw@mail.gmail.com>
Date: Tue, 6 May 2025 20:43:43 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: Martin KaFai Lau <martin.lau@...ux.dev>, Jakub Sitnicki <jakub@...udflare.com>, 
	John Fastabend <john.fastabend@...il.com>, Cong Wang <xiyou.wangcong@...il.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Jesper Dangaard Brouer <hawk@...nel.org>, LKML <linux-kernel@...r.kernel.org>, 
	bpf <bpf@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, 
	linux-trace-kernel <linux-trace-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH bpf-next v4 1/2] bpf, sockmap: Introduce tracing
 capability for sockmap

On Tue, May 6, 2025 at 8:37 PM Jiayuan Chen <jiayuan.chen@...ux.dev> wrote:
>
> May 7, 2025 at 04:24, "Martin KaFai Lau" <martin.lau@...ux.dev> wrote:
>
> >
> > On 5/5/25 7:51 PM, Jiayuan Chen wrote:
> >
> > >
> > > Sockmap has the same high-performance forwarding capability as XDP, but
> > >
> > >  operates at Layer 7.
> > >
> > >  Introduce tracing capability for sockmap, to trace the execution results
> > >
> > >  of BPF programs without modifying the programs themselves, similar to
> > >
> > >  the existing trace_xdp_redirect{_map}.
> > >
> >
> > There were advancements in bpf tracing since the trace_xdp_xxx additions.
> >
> > Have you considered the fexit bpf prog and why it is not sufficient ?
> >
>
> 1.This patchset prints a large amount of information (e.g. inode ID, etc.),
> some of which require kernel-internal helpers to access. These helpers are
> not currently available as kfuncs, making it difficult to implement
> equivalent functionality with fentry/fexit.
>
> 2. skb->_sk_redir implicitly stores both a redir action and the socket address
> in a single field. Decoding this structure in fentry/fexit would require
> duplicating kernel-internal logic in BPF programs. This creates maintenance
> risks, as any future changes to the kernel's internal representation would
> necessitate corresponding updates to the BPF programs.
>
> 3. Similar to the debate between using built-in tracepoints vs kprobes/fentry,
> each approach has its tradeoffs. The key advantage of a built-in tracepoint is
> seamless integration with existing tools like perf and bpftrace, which natively
> support tracepoint-based tracing. For example, simply executing
> 'perf trace -e 'sockmap:*' ./producer' could provide sufficient visibility
> without custom BPF programs.

Similar to Martin I don't buy these excuses.
For your own debugging you can write bpftrace prog that will
print exact same stats and numbers without adding any kernel code.

We add tracepoints when they're in the path that is hard to get to
with tracing tools. Like functions are partially inlined.
Here it's not the case.
You want to add a tracepoint right after your own bpf prog
finished. All these debugging could have been part of your
skmsg program.

pw-bot: cr