[PATCH bpf-next 1/2] libbpf: Move XDP frags flag to prog_flags

[PATCH bpf-next 1/2] libbpf: Move XDP frags flag to prog_flags

[Toke Høiland-Jørgensen]

The libbpf section definition for XDP frags support stores the flags bit
in the private section definition cookie from object open to load time.
This has the unfortunate consequence that API consumers cannot see (or
manipulate) the flag between object open and program load.

In particular, libxdp has special handling of frags-enabled programs to
make them compatible with the dispatcher. This doesn't work on XDP
programs that enable frags through the 'xdp.frags' section definition
because the flag is not visible through bpf_program__flags()[0].

Fix this by changing how libbpf loads the 'xdp.frags' section: instead
of using the private section definition cookie, add a setup function to
the section definition that stores the flag in the prog_flags field of
struct bpf_program.

[0] https://github.com/xdp-project/xdp-tools/issues/587

Fixes: 082c4bfba4f7 ("libbpf: Add SEC name for xdp frags programs")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
 tools/lib/bpf/libbpf.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index b749c01742ee..7d6f0fe518d9 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -420,10 +420,8 @@ enum sec_def_flags {
 	SEC_ATTACH_BTF = 4,
 	/* BPF program type allows sleeping/blocking in kernel */
 	SEC_SLEEPABLE = 8,
-	/* BPF program support non-linear XDP buffer */
-	SEC_XDP_FRAGS = 16,
 	/* Setup proper attach type for usdt probes. */
-	SEC_USDT = 32,
+	SEC_USDT = 16,
 };
 
 struct bpf_sec_def {
@@ -7879,6 +7877,12 @@ static int tracing_multi_mod_fd(struct bpf_program *prog, int *btf_obj_fd)
 	return 0;
 }
 
+static int setup_xdp_frags(struct bpf_program *prog, long cookie)
+{
+	prog->prog_flags |= BPF_F_XDP_HAS_FRAGS;
+	return 0;
+}
+
 /* this is called as prog->sec_def->prog_prepare_load_fn for libbpf-supported sec_defs */
 static int libbpf_prepare_prog_load(struct bpf_program *prog,
 				    struct bpf_prog_load_opts *opts, long cookie)
@@ -7892,9 +7896,6 @@ static int libbpf_prepare_prog_load(struct bpf_program *prog,
 	if (def & SEC_SLEEPABLE)
 		opts->prog_flags |= BPF_F_SLEEPABLE;
 
-	if (prog->type == BPF_PROG_TYPE_XDP && (def & SEC_XDP_FRAGS))
-		opts->prog_flags |= BPF_F_XDP_HAS_FRAGS;
-
 	/* special check for usdt to use uprobe_multi link */
 	if ((def & SEC_USDT) && kernel_supports(prog->obj, FEAT_UPROBE_MULTI_LINK)) {
 		/* for BPF_TRACE_UPROBE_MULTI, user might want to query expected_attach_type
@@ -10182,11 +10183,11 @@ static const struct bpf_sec_def section_defs[] = {
 	SEC_DEF("iter+",		TRACING, BPF_TRACE_ITER, SEC_ATTACH_BTF, attach_iter),
 	SEC_DEF("iter.s+",		TRACING, BPF_TRACE_ITER, SEC_ATTACH_BTF | SEC_SLEEPABLE, attach_iter),
 	SEC_DEF("syscall",		SYSCALL, 0, SEC_SLEEPABLE),
-	SEC_DEF("xdp.frags/devmap",	XDP, BPF_XDP_DEVMAP, SEC_XDP_FRAGS),
+	SEC_DEF("xdp.frags/devmap",	XDP, BPF_XDP_DEVMAP, SEC_NONE, .prog_setup_fn = setup_xdp_frags),
 	SEC_DEF("xdp/devmap",		XDP, BPF_XDP_DEVMAP, SEC_ATTACHABLE),
-	SEC_DEF("xdp.frags/cpumap",	XDP, BPF_XDP_CPUMAP, SEC_XDP_FRAGS),
+	SEC_DEF("xdp.frags/cpumap",	XDP, BPF_XDP_CPUMAP, SEC_NONE, .prog_setup_fn = setup_xdp_frags),
 	SEC_DEF("xdp/cpumap",		XDP, BPF_XDP_CPUMAP, SEC_ATTACHABLE),
-	SEC_DEF("xdp.frags",		XDP, BPF_XDP, SEC_XDP_FRAGS),
+	SEC_DEF("xdp.frags",		XDP, BPF_XDP, SEC_NONE, .prog_setup_fn = setup_xdp_frags),
 	SEC_DEF("xdp",			XDP, BPF_XDP, SEC_ATTACHABLE_OPT),
 	SEC_DEF("perf_event",		PERF_EVENT, 0, SEC_NONE),
 	SEC_DEF("lwt_in",		LWT_IN, 0, SEC_NONE),
-- 
2.55.0

[PATCH bpf-next 2/2] bpf: selftests: Check for XDP frags flag in bpf_program__flags()

[Toke Høiland-Jørgensen]

Add a check that the BPF_F_XDP_HAS_FRAGS flag shows up in
bpf_program__flags() when opening a BPF program with the 'xdp.flags'
section definition.

Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
 tools/testing/selftests/bpf/prog_tests/xdp_adjust_frags.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_adjust_frags.c b/tools/testing/selftests/bpf/prog_tests/xdp_adjust_frags.c
index fce203640f8c..a894b1ab46f4 100644
--- a/tools/testing/selftests/bpf/prog_tests/xdp_adjust_frags.c
+++ b/tools/testing/selftests/bpf/prog_tests/xdp_adjust_frags.c
@@ -18,6 +18,9 @@ static void test_xdp_update_frags(void)
 		return;
 
 	prog = bpf_object__next_program(obj, NULL);
+	ASSERT_EQ(bpf_program__flags(prog) & BPF_F_XDP_HAS_FRAGS,
+		  BPF_F_XDP_HAS_FRAGS, "frags in program flags");
+
 	if (bpf_object__load(obj))
 		return;
 
-- 
2.55.0

Re: [PATCH bpf-next 1/2] libbpf: Move XDP frags flag to prog_flags

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 5500 bytes --]

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b749c01742ee0..7d6f0fe518d99 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -7879,6 +7877,12 @@ static int tracing_multi_mod_fd(struct bpf_program *prog, int *btf_obj_fd)
>  	return 0;
>  }
>
> +static int setup_xdp_frags(struct bpf_program *prog, long cookie)
> +{
> +	prog->prog_flags |= BPF_F_XDP_HAS_FRAGS;
> +	return 0;
> +}

Does storing BPF_F_XDP_HAS_FRAGS in prog->prog_flags here break callers
that use bpf_program__set_flags()?

bpf_program__set_flags() overwrites rather than OR-ing:

    int bpf_program__set_flags(struct bpf_program *prog, __u32 flags)
    {
            ...
            prog->prog_flags = flags;
    }

Previously the flag was OR'd into the load-time opts by
libbpf_prepare_prog_load(), so it survived any user manipulation of
prog_flags between open and load. The new code latches it into
prog->prog_flags at open time, so it's lost whenever a caller assigns
prog_flags instead of OR-ing.

bpf_object_load_prog() passes prog->prog_flags straight to the kernel:

    load_attr.prog_flags = prog->prog_flags;

Two in-tree callers do exactly that on SEC("xdp.frags") programs.

bpftool (tools/bpf/bpftool/prog.c), i.e. 'bpftool prog load FILE PIN
xdpmeta_dev DEV':

    if (prog_type == BPF_PROG_TYPE_XDP && xdpmeta_ifindex) {
            bpf_program__set_flags(pos, BPF_F_XDP_DEV_BOUND_ONLY);
            bpf_program__set_ifindex(pos, xdpmeta_ifindex);

Before: final prog_flags = BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS.
After:  final prog_flags = BPF_F_XDP_DEV_BOUND_ONLY only.

tools/testing/selftests/bpf/xdp_hw_metadata.c on program "rx", whose
section is SEC("xdp.frags") (progs/xdp_hw_metadata.c):

    prog = bpf_object__find_program_by_name(bpf_obj->obj, "rx");
    bpf_program__set_ifindex(prog, ifindex);
    bpf_program__set_flags(prog, BPF_F_XDP_DEV_BOUND_ONLY);

The load still succeeds (BPF_F_XDP_HAS_FRAGS is optional,
kernel/bpf/syscall.c:2936), so the loss is silent:
kernel/bpf/syscall.c:3062 sets prog->aux->xdp_has_frags = 0, after which
net/core/dev.c:10418 refuses to attach the program on a device whose MTU
needs more than one buffer, skb_cow_data_for_xdp() returns -EINVAL
(net/core/skbuff.c:1021), and drivers such as mlx5 (en_main.c:4701)
restrict the RQ configuration. A multi-buffer XDP program is silently
downgraded to a single-buffer one.

Note the resulting asymmetry inside libbpf_prepare_prog_load() itself:
the other section-implied flag is still applied at load time:

    if (def & SEC_SLEEPABLE)
            opts->prog_flags |= BPF_F_SLEEPABLE;

so BPF_F_SLEEPABLE survives bpf_program__set_flags(prog, 0) while
BPF_F_XDP_HAS_FRAGS no longer does. Keeping the load-time 'opts->prog_flags
|= BPF_F_XDP_HAS_FRAGS' in addition to the new prog_flags initialisation,
or having bpf_program__set_flags() preserve section-implied bits, would give
visibility without breaking existing callers.

>
>  /* this is called as prog->sec_def->prog_prepare_load_fn for libbpf-supported sec_defs */
>  static int libbpf_prepare_prog_load(struct bpf_program *prog,
>  				    struct bpf_prog_load_opts *opts, long cookie)
>  @@ -7892,9 +7896,6 @@ static int libbpf_prepare_prog_load(struct bpf_program *prog,
>  	if (def & SEC_SLEEPABLE)
>  		opts->prog_flags |= BPF_F_SLEEPABLE;
>
> -	if (prog->type == BPF_PROG_TYPE_XDP && (def & SEC_XDP_FRAGS))
> -		opts->prog_flags |= BPF_F_XDP_HAS_FRAGS;
> -

Should setup_xdp_frags() keep a program type guard?

The deleted load-time code was guarded:

    if (prog->type == BPF_PROG_TYPE_XDP && (def & SEC_XDP_FRAGS))
            opts->prog_flags |= BPF_F_XDP_HAS_FRAGS;

setup_xdp_frags() has no equivalent guard, and because the flag is now
latched into prog->prog_flags at open time it also survives a later type
change. bpf_program__set_type() only clears the section handler, not the
flags:

    prog->type = type;
    ...
    if (prog->sec_def != &custom_fallback_def)
            prog->sec_def = NULL;

So for a SEC("xdp.frags") program retyped to something else, the old code
dropped BPF_F_XDP_HAS_FRAGS while the new code keeps it.

bpftool retypes on request:

    if (bpf_program__type(pos) != prog_type)
            bpf_program__set_type(pos, prog_type);

'bpftool prog load xdp_frags.o PIN type sched_cls dev DEV' now reaches
bpf_prog_dev_bound_init() with BPF_F_XDP_HAS_FRAGS but without
BPF_F_XDP_DEV_BOUND_ONLY and is rejected:

    if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS &&
        !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY))
            return -EINVAL;               /* kernel/bpf/offload.c */

where it previously loaded. Without an ifindex the load still succeeds, but
a non-XDP program ends up with prog->aux->xdp_has_frags = 1
(kernel/bpf/syscall.c:3062), which changes prog-array owner compatibility
('map->owner->xdp_has_frags == aux->xdp_has_frags', kernel/bpf/core.c:2541)
and so can make a tail-call map setup fail.

The trigger requires a deliberate retype, but the guard removal is a
behaviour change that the changelog does not mention. If the flag is meant
to be XDP-only, should setup_xdp_frags() keep the type test or should
bpf_program__set_type() drop the bit when moving away from
BPF_PROG_TYPE_XDP?

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33062649421

Re: [PATCH bpf-next 1/2] libbpf: Move XDP frags flag to prog_flags

[Toke Høiland-Jørgensen]

bot+bpf-ci@kernel.org writes:

>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index b749c01742ee0..7d6f0fe518d99 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>
> [ ... ]
>
>> @@ -7879,6 +7877,12 @@ static int tracing_multi_mod_fd(struct bpf_program *prog, int *btf_obj_fd)
>>  	return 0;
>>  }
>>
>> +static int setup_xdp_frags(struct bpf_program *prog, long cookie)
>> +{
>> +	prog->prog_flags |= BPF_F_XDP_HAS_FRAGS;
>> +	return 0;
>> +}
>
> Does storing BPF_F_XDP_HAS_FRAGS in prog->prog_flags here break callers
> that use bpf_program__set_flags()?
>
> bpf_program__set_flags() overwrites rather than OR-ing:
>
>     int bpf_program__set_flags(struct bpf_program *prog, __u32 flags)
>     {
>             ...
>             prog->prog_flags = flags;
>     }
>
> Previously the flag was OR'd into the load-time opts by
> libbpf_prepare_prog_load(), so it survived any user manipulation of
> prog_flags between open and load. The new code latches it into
> prog->prog_flags at open time, so it's lost whenever a caller assigns
> prog_flags instead of OR-ing.

Making it possible to manipulate the flag after loading is the whole
point of the patch, so this is expected. As for users like:

> bpf_object_load_prog() passes prog->prog_flags straight to the kernel:
>
>     load_attr.prog_flags = prog->prog_flags;
>
> Two in-tree callers do exactly that on SEC("xdp.frags") programs.
>
> bpftool (tools/bpf/bpftool/prog.c), i.e. 'bpftool prog load FILE PIN
> xdpmeta_dev DEV':
>
>     if (prog_type == BPF_PROG_TYPE_XDP && xdpmeta_ifindex) {
>             bpf_program__set_flags(pos, BPF_F_XDP_DEV_BOUND_ONLY);
>             bpf_program__set_ifindex(pos, xdpmeta_ifindex);

...doing a set_flags without preserving the existing flags will lead to
clobbering, that's what's implied by the API? So any users doing that
are buggy, I'd argue.

> Keeping the load-time 'opts->prog_flags
> |= BPF_F_XDP_HAS_FRAGS' in addition to the new prog_flags initialisation,
> or having bpf_program__set_flags() preserve section-implied bits, would give
> visibility without breaking existing callers.

Both of these options will still make it impossible to turn off the
frags bit after loading the object. I guess we could do the "preserve
section-implied bits" part and add an explicit
bpf_program__clear_flags() to remove everything. What do others think?

>>  /* this is called as prog->sec_def->prog_prepare_load_fn for libbpf-supported sec_defs */
>>  static int libbpf_prepare_prog_load(struct bpf_program *prog,
>>  				    struct bpf_prog_load_opts *opts, long cookie)
>>  @@ -7892,9 +7896,6 @@ static int libbpf_prepare_prog_load(struct bpf_program *prog,
>>  	if (def & SEC_SLEEPABLE)
>>  		opts->prog_flags |= BPF_F_SLEEPABLE;
>>
>> -	if (prog->type == BPF_PROG_TYPE_XDP && (def & SEC_XDP_FRAGS))
>> -		opts->prog_flags |= BPF_F_XDP_HAS_FRAGS;
>> -
>
> Should setup_xdp_frags() keep a program type guard?

No, the setup callback callback is called too early for this to make
sense. However:

> The trigger requires a deliberate retype, but the guard removal is a
> behaviour change that the changelog does not mention. If the flag is meant
> to be XDP-only, should setup_xdp_frags() keep the type test or should
> bpf_program__set_type() drop the bit when moving away from
> BPF_PROG_TYPE_XDP?

Clearing the type-specific flags on type change could make sense. I can
add that in v2 if others agree?

-Toke

Re: [PATCH bpf-next 1/2] libbpf: Move XDP frags flag to prog_flags

[Andrii Nakryiko]

On Thu, Aug 27, 2026 at 6:27 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> bot+bpf-ci@kernel.org writes:
>
> >> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> >> index b749c01742ee0..7d6f0fe518d99 100644
> >> --- a/tools/lib/bpf/libbpf.c
> >> +++ b/tools/lib/bpf/libbpf.c
> >
> > [ ... ]
> >
> >> @@ -7879,6 +7877,12 @@ static int tracing_multi_mod_fd(struct bpf_program *prog, int *btf_obj_fd)
> >>      return 0;
> >>  }
> >>
> >> +static int setup_xdp_frags(struct bpf_program *prog, long cookie)
> >> +{
> >> +    prog->prog_flags |= BPF_F_XDP_HAS_FRAGS;
> >> +    return 0;
> >> +}
> >
> > Does storing BPF_F_XDP_HAS_FRAGS in prog->prog_flags here break callers
> > that use bpf_program__set_flags()?
> >
> > bpf_program__set_flags() overwrites rather than OR-ing:
> >
> >     int bpf_program__set_flags(struct bpf_program *prog, __u32 flags)
> >     {
> >             ...
> >             prog->prog_flags = flags;
> >     }
> >
> > Previously the flag was OR'd into the load-time opts by
> > libbpf_prepare_prog_load(), so it survived any user manipulation of
> > prog_flags between open and load. The new code latches it into
> > prog->prog_flags at open time, so it's lost whenever a caller assigns
> > prog_flags instead of OR-ing.
>
> Making it possible to manipulate the flag after loading is the whole
> point of the patch, so this is expected. As for users like:
>
> > bpf_object_load_prog() passes prog->prog_flags straight to the kernel:
> >
> >     load_attr.prog_flags = prog->prog_flags;
> >
> > Two in-tree callers do exactly that on SEC("xdp.frags") programs.
> >
> > bpftool (tools/bpf/bpftool/prog.c), i.e. 'bpftool prog load FILE PIN
> > xdpmeta_dev DEV':
> >
> >     if (prog_type == BPF_PROG_TYPE_XDP && xdpmeta_ifindex) {
> >             bpf_program__set_flags(pos, BPF_F_XDP_DEV_BOUND_ONLY);
> >             bpf_program__set_ifindex(pos, xdpmeta_ifindex);
>
> ...doing a set_flags without preserving the existing flags will lead to
> clobbering, that's what's implied by the API? So any users doing that
> are buggy, I'd argue.
>
> > Keeping the load-time 'opts->prog_flags
> > |= BPF_F_XDP_HAS_FRAGS' in addition to the new prog_flags initialisation,
> > or having bpf_program__set_flags() preserve section-implied bits, would give
> > visibility without breaking existing callers.
>
> Both of these options will still make it impossible to turn off the
> frags bit after loading the object. I guess we could do the "preserve
> section-implied bits" part and add an explicit
> bpf_program__clear_flags() to remove everything. What do others think?
>
> >>  /* this is called as prog->sec_def->prog_prepare_load_fn for libbpf-supported sec_defs */
> >>  static int libbpf_prepare_prog_load(struct bpf_program *prog,
> >>                                  struct bpf_prog_load_opts *opts, long cookie)
> >>  @@ -7892,9 +7896,6 @@ static int libbpf_prepare_prog_load(struct bpf_program *prog,
> >>      if (def & SEC_SLEEPABLE)
> >>              opts->prog_flags |= BPF_F_SLEEPABLE;
> >>
> >> -    if (prog->type == BPF_PROG_TYPE_XDP && (def & SEC_XDP_FRAGS))
> >> -            opts->prog_flags |= BPF_F_XDP_HAS_FRAGS;
> >> -
> >
> > Should setup_xdp_frags() keep a program type guard?
>
> No, the setup callback callback is called too early for this to make
> sense. However:
>
> > The trigger requires a deliberate retype, but the guard removal is a
> > behaviour change that the changelog does not mention. If the flag is meant
> > to be XDP-only, should setup_xdp_frags() keep the type test or should
> > bpf_program__set_type() drop the bit when moving away from
> > BPF_PROG_TYPE_XDP?
>
> Clearing the type-specific flags on type change could make sense. I can
> add that in v2 if others agree?

no, let's not.

But instead of making this XDP-specific custom callback, let's have a
generic default libbpf setup callback that will do the same for
BPF_F_SLEEPABLE, seems a fair game (and technically will allow to
dynamically downgrade sleepable to non-sleepable, if there is ever any
good reason to do that)

pw-bot: cr

>
> -Toke
>