From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96AD425DAFB; Wed, 30 Apr 2025 15:55:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746028519; cv=none; b=lF51ayRCJF4ZQ4Hm56WjhQj80MYYarqG0jA5ZwDeOvZ3JZ+yxuYAzdkoQ9cUFX087QscUF/au/5vSW+gsHl5sWMoaqg+09mFcuHTTRbloMt2YLWhRNZW0QMbAFVc/0tj7ix3WDdR7vz4k6bgHBP0qhyhdKUXGOif/I1JJzvDHaI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746028519; c=relaxed/simple; bh=itiBlsf6zR4RTlm3hf+QfHFNY4vVsdzz2uVhJ45Z5FI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gRiBVHqSNZIy0cyh/p2c7MyFXczaNQEqhgMxGz+Au5oSA7cRyNw68EAUB8va6eUxUoo8LPenUhJeTNUdLLZV6Gw/yqo3u33klSNSCFaZsQJzRF8AoHxrt5EV76TVi9DFRoNTO1Ykc//4vAna04Wzv4zNA15ZjUdibryBbt77b3M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=jEUP/GLo; arc=none smtp.client-ip=95.215.58.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="jEUP/GLo" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1746028504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x01/YentqQxiWV+z2dsRSAIeIX6UbbCKUGdMPakv0qE=; b=jEUP/GLoxJGvhRlAHo8UUY72GYTKU2U7nYQiDnmfjuRerBfvwIZZMpmwdytWhh/xlnA4yk jTrmdGlsY2YmIOSEJ+DH24bkZzjHXIG/QOIjHqjNAslgaJR3ZYdM4p74rpLyDEv/HqR/5U MM7aIhHbnP3NPMi6VPkKCuFv9s+4YvM= Date: Wed, 30 Apr 2025 23:54:46 +0800 Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next 1/4] bpf: Allow get_func_[arg|arg_cnt] helpers in raw tracepoint programs To: Kafai Wan , Alexei Starovoitov Cc: Song Liu , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Matt Bobrowski , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Mykola Lysenko , Shuah Khan , LKML , bpf , linux-trace-kernel , Network Development , "open list:KERNEL SELFTEST FRAMEWORK" References: <20250426160027.177173-1-mannkafai@gmail.com> <20250426160027.177173-2-mannkafai@gmail.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Leon Hwang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2025/4/30 20:43, Kafai Wan wrote: > On Wed, Apr 30, 2025 at 10:46 AM Alexei Starovoitov > wrote: >> >> On Sat, Apr 26, 2025 at 9:00 AM KaFai Wan wrote: >>> [...] >>> @@ -2312,7 +2322,7 @@ void __bpf_trace_run(struct bpf_raw_tp_link *link, u64 *args) >>> #define REPEAT(X, FN, DL, ...) REPEAT_##X(FN, DL, __VA_ARGS__) >>> >>> #define SARG(X) u64 arg##X >>> -#define COPY(X) args[X] = arg##X >>> +#define COPY(X) args[X + 1] = arg##X >>> >>> #define __DL_COM (,) >>> #define __DL_SEM (;) >>> @@ -2323,9 +2333,10 @@ void __bpf_trace_run(struct bpf_raw_tp_link *link, u64 *args) >>> void bpf_trace_run##x(struct bpf_raw_tp_link *link, \ >>> REPEAT(x, SARG, __DL_COM, __SEQ_0_11)) \ >>> { \ >>> - u64 args[x]; \ >>> + u64 args[x + 1]; \ >>> + args[0] = x; \ >>> REPEAT(x, COPY, __DL_SEM, __SEQ_0_11); \ >>> - __bpf_trace_run(link, args); \ >>> + __bpf_trace_run(link, args + 1); \ >> >> This is neat, but what is this for? >> The program that attaches to a particular raw_tp knows what it is >> attaching to and how many arguments are there, >> so bpf_get_func_arg_cnt() is a 5th wheel. >> >> If the reason is "for completeness" then it's not a good reason >> to penalize performance. Though it's just an extra 8 byte of stack >> and a single store of a constant. >> > If we try to capture all arguments of a specific raw_tp in tracing programs, > We first obtain the arguments count from the format file in debugfs or BTF > and pass this count to the BPF program via .bss section or cookie (if > available). > > If we store the count in ctx and get it via get_func_arg_cnt helper in > the BPF program， > a) It's easier and more efficient to get the arguments count in the BPF program. > b) It could use a single BPF program to capture arguments for multiple raw_tps, > reduce the number of BPF programs when massive tracing. > bpf_get_func_arg() will be very helpful for bpfsnoop[1] when tracing tp_btf. In bpfsnoop, it can generate a small snippet of bpf instructions to use bpf_get_func_arg() for retrieving and filtering arguments. For example, with the netif_receive_skb tracepoint, bpfsnoop can use bpf_get_func_arg() to filter the skb argument using pcap-filter(7)[2] or a custom attribute-based filter. This will allow bpfsnoop to trace multiple tracepoints using a single bpf program code. [1] https://github.com/bpfsnoop/bpfsnoop [2] https://www.tcpdump.org/manpages/pcap-filter.7.html Thanks, Leon