linux-kernel - Re: [PATCH net-next] udp: Add tracepoint for udp

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: <20250418083351.20a60e64@gandalf.local.home>
Date: Fri, 18 Apr 2025 08:33:51 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: David Ahern <dsahern@...nel.org>
Cc: Breno Leitao <leitao@...ian.org>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>, 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>, kuniyu@...zon.com, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 yonghong.song@...ux.dev, song@...nel.org, kernel-team@...a.com
Subject: Re: [PATCH net-next] udp: Add tracepoint for udp_sendmsg()

On Thu, 17 Apr 2025 21:57:56 -0700
David Ahern <dsahern@...nel.org> wrote:

> On 4/17/25 10:00 AM, Breno Leitao wrote:
> >> $ git grep trace_ net drivers/net | grep _tp
> >> net/bpf/test_run.c:	trace_bpf_trigger_tp(nonce);
> >> net/ipv4/tcp_input.c:	trace_tcp_cwnd_reduction_tp(sk,
> >> newly_acked_sacked, newly_lost, flag);  
> > 
> > Do we want to rename them and remove the _tp? I suppose it is OK given
> > that tracepoints are not expected to be stable?
> > 
> > Also, if we have consensus about this patch, I will remove the _tp from
> > it.
> >   
> 
> I am only asking for consistency. Based on existing networking
> instances, consistency is no _tp suffix.

I was looking at what other tracepoints have "_tp" and found a few. What it
appears to be is that the "_tp" tracepoints are defined by:

  DECLARE_TRACEPOINT()

and have no corresponding trace event in tracefs (/sys/kernel/tracing/events).

I like that distinction because it lets the developer know that this
tracepoint is in kernel only, and not exposed to user space.

Perhaps it should stay as "_tp()" if it's not exposed via tracefs.

In fact, if there is a clean up, it should be adding "_tp" to all
tracepoints that do not have a corresponding trace event attached to them.
As they are in kernel only, that change should not cause any ABI breakage.

-- Steve