Re: [PATCH net-next v2 2/2] trace: tcp: Add tracepoint for tcp_sendmsg_locked()

[Kuniyuki Iwashima <kuniyu@amazon.com>]

From: Breno Leitao <leitao@debian.org>
Date: Tue, 8 Apr 2025 10:01:05 -0700
> On Tue, Apr 08, 2025 at 09:16:51AM -0600, David Ahern wrote:
> > On 4/8/25 8:27 AM, Breno Leitao wrote:
> > > 
> > > 	SEC("tracepoint/tcp/tcp_sendmsg_locked")
> > 
> > Try `raw_tracepoint/tcp/tcp_sendmsg_locked`.
> > 
> > This is the form I use for my tracepoint based packet capture (not tied
> > to this tracepoint, but traces inside our driver) and it works fine.
> 
> Thanks. I was not able to get this crashing as well. In fact, the
> following program fails to be loaded:
> 
> 	SEC("raw_tracepoint/tcp/tcp_sendmsg_locked")

Try SEC("tp_btf/tcp_sendmsg_locked") and access the raw argument
(struct sk_buff *skb) instead of bpf_raw_tracepoint_args.

The original report used it and I was able to reproduce it
at that time.

https://lore.kernel.org/netdev/Z50zebTRzI962e6X@debian.debian/


> 	int bpf_tcp_sendmsg_locked(struct bpf_raw_tracepoint_args *ctx)
> 	{
> 		void *skb_addr = (void *) ctx->args[0];
> 
> 		bpf_printk("deref %d\n", *(int *) skb_addr);
> 
> 		return 0;
> 	}
> 
> libbpf refuses to load it, and drumps:
> 
> 	libbpf: prog 'bpf_tcp_sendmsg_locked': BPF program load failed: Permission denied
> 	libbpf: prog 'bpf_tcp_sendmsg_locked': -- BEGIN PROG LOAD LOG --
> 	0: R1=ctx() R10=fp0
> 	; void *skb_addr = (void *) ctx->args[0]; @ tcp_sendmsg_locked_bpf.c:18
> 	0: (79) r1 = *(u64 *)(r1 +0)          ; R1_w=scalar()
> 	; bpf_printk("deref %d\n", *(int *) skb_addr); @ tcp_sendmsg_locked_bpf.c:20
> 	1: (61) r3 = *(u32 *)(r1 +0)
> 	R1 invalid mem access 'scalar'
> 	processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
> 	-- END PROG LOAD LOG --
> 	libbpf: prog 'bpf_tcp_sendmsg_locked': failed to load: -13
> 	libbpf: failed to load object 'tcp_sendmsg_locked_bpf.o'
> 	Failed to load BPF object: -13
> 
> > As suggested, you might need to update raw_tp_null_args
> 
> Thanks for confirming it. I will update raw_tp_null_args, assuming that
> the problem exists but I am failing to reproduce it.
> 
> I will send an updated version soon.