All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: martin.lau@linux.dev, ast@kernel.org, andrii@kernel.org,
	tony.ambardar@gmail.com, alexis.lothore@bootlin.com
Cc: eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
	haoluo@google.com, jolsa@kernel.org, mykolal@fb.com,
	bpf@vger.kernel.org, dwarves@vger.kernel.org
Subject: Re: [RFC bpf-next 1/3] libbpf: update BPF_PROG2() to handle empty structs
Date: Thu, 8 May 2025 14:45:58 +0100	[thread overview]
Message-ID: <ae994be9-e0d8-45e4-8518-00488cbe3a1c@oracle.com> (raw)
In-Reply-To: <20250508132237.1817317-2-alan.maguire@oracle.com>

On 08/05/2025 14:22, Alan Maguire wrote:
> In the kernel we occasionally find empty structs as parameters to
> functions, usually because some arch-specific field(s) are not present.
> Ensure that when such structs are used as parameters to functions we
> handle the fact that no registers are used in their representation.
> 
> Deliberately not using a Fixes: tag here because for this to be useful
> we need a more recent pahole with [1].
>

apologies, this isn't quite right; we had exceptions in pahole encoding
ensuring struct parameters didn't require strict parameter/register
matching, it's just that moving to a size-based determination in the v1
of Tony's patch left zero-sized structs out. So we should probably mention

Fixes: 34586d29f8df ("libbpf: Add new BPF_PROG2 macro")

> [1] https://lore.kernel.org/dwarves/20250502070318.1561924-1-tony.ambardar@gmail.com/
> 
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  tools/lib/bpf/bpf_tracing.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/lib/bpf/bpf_tracing.h b/tools/lib/bpf/bpf_tracing.h
> index a8f6cd4841b0..7629650251dc 100644
> --- a/tools/lib/bpf/bpf_tracing.h
> +++ b/tools/lib/bpf/bpf_tracing.h
> @@ -694,12 +694,13 @@ ____##name(unsigned long long *ctx, ##args)
>  #endif
>  
>  #define ___bpf_treg_cnt(t) \
> +	__builtin_choose_expr(sizeof(t) == 0, 0,	\
>  	__builtin_choose_expr(sizeof(t) == 1, 1,	\
>  	__builtin_choose_expr(sizeof(t) == 2, 1,	\
>  	__builtin_choose_expr(sizeof(t) == 4, 1,	\
>  	__builtin_choose_expr(sizeof(t) == 8, 1,	\
>  	__builtin_choose_expr(sizeof(t) == 16, 2,	\
> -			      (void)0)))))
> +			      (void)0))))))
>  
>  #define ___bpf_reg_cnt0()		(0)
>  #define ___bpf_reg_cnt1(t, x)		(___bpf_reg_cnt0() + ___bpf_treg_cnt(t))
> @@ -717,12 +718,13 @@ ____##name(unsigned long long *ctx, ##args)
>  #define ___bpf_reg_cnt(args...)	 ___bpf_apply(___bpf_reg_cnt, ___bpf_narg2(args))(args)
>  
>  #define ___bpf_union_arg(t, x, n) \
> +	__builtin_choose_expr(sizeof(t) == 0, ({ t ___t; ___t; }), \
>  	__builtin_choose_expr(sizeof(t) == 1, ({ union { __u8 z[1]; t x; } ___t = { .z = {ctx[n]}}; ___t.x; }), \
>  	__builtin_choose_expr(sizeof(t) == 2, ({ union { __u16 z[1]; t x; } ___t = { .z = {ctx[n]} }; ___t.x; }), \
>  	__builtin_choose_expr(sizeof(t) == 4, ({ union { __u32 z[1]; t x; } ___t = { .z = {ctx[n]} }; ___t.x; }), \
>  	__builtin_choose_expr(sizeof(t) == 8, ({ union { __u64 z[1]; t x; } ___t = {.z = {ctx[n]} }; ___t.x; }), \
>  	__builtin_choose_expr(sizeof(t) == 16, ({ union { __u64 z[2]; t x; } ___t = {.z = {ctx[n], ctx[n + 1]} }; ___t.x; }), \
> -			      (void)0)))))
> +			      (void)0))))))
>  
>  #define ___bpf_ctx_arg0(n, args...)
>  #define ___bpf_ctx_arg1(n, t, x)		, ___bpf_union_arg(t, x, n - ___bpf_reg_cnt1(t, x))


  reply	other threads:[~2025-05-08 13:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08 13:22 [RFC bpf-next 0/3] bpf: handle 0-sized structs properly Alan Maguire
2025-05-08 13:22 ` [RFC bpf-next 1/3] libbpf: update BPF_PROG2() to handle empty structs Alan Maguire
2025-05-08 13:45   ` Alan Maguire [this message]
2025-05-08 13:22 ` [RFC bpf-next 2/3] bpf: allow 0-sized structs as function parameters Alan Maguire
2025-05-08 13:22 ` [RFC bpf-next 3/3] selftests/bpf: add 0-length struct testing to tracing_struct tests Alan Maguire
2025-05-09 18:40 ` [RFC bpf-next 0/3] bpf: handle 0-sized structs properly Andrii Nakryiko
2025-05-12  9:17   ` Tony Ambardar
2025-05-14 10:30     ` Alan Maguire
2025-05-14 16:22       ` Andrii Nakryiko
2025-05-15  8:02         ` Tony Ambardar
2025-05-15 16:23           ` Andrii Nakryiko
2025-05-15 10:56   ` Alan Maguire
2025-05-20  8:59     ` Alan Maguire
2025-05-21  0:58       ` Tony Ambardar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae994be9-e0d8-45e4-8518-00488cbe3a1c@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=tony.ambardar@gmail.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.