On Tue, Nov 8, 2022 at 6:07 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>
> From: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
>
> BPF ABI always uses 64-bit return value, but so far __bpf_prog_run and
> higher level wrappers always truncated the return value to 32-bit. We
> want to be able to introduce a new BPF program type that returns a
> PTR_TO_BTF_ID or NULL from the BPF program to the caller context in the
> kernel. To be able to use this returned pointer value, the bpf_prog_run
> invocation needs to be able to return a 64-bit value, so update the
> definitions to allow this.
...
> -static __always_inline u32 __bpf_prog_run(const struct bpf_prog *prog,
> +static __always_inline u64 __bpf_prog_run(const struct bpf_prog *prog,
> const void *ctx,
> bpf_dispatcher_fn dfunc)
> {
> - u32 ret;
> + u64 ret;
>
> cant_migrate();
> if (static_branch_unlikely(&bpf_stats_enabled_key)) {
> @@ -602,7 +602,7 @@ static __always_inline u32 __bpf_prog_run(const struct bpf_prog *prog,
> return ret;
> }
>
> -static __always_inline u32 bpf_prog_run(const struct bpf_prog *prog, const void *ctx)
> +static __always_inline u64 bpf_prog_run(const struct bpf_prog *prog, const void *ctx)
> {
> return __bpf_prog_run(prog, ctx, bpf_dispatcher_nop_func);
> }
I suspect 32-bit archs with JITs are partially broken with this change.
As long as progs want to return pointers it's ok, but actual
64-bit values will be return garbage in upper 32-bit, since 32-bit
JITs won't populate the upper bits.
I don't think changing u32->long retval is a good idea either,
since BPF ISA has to be stable regardless of underlying arch.
The u32->u64 transition is good long term, but let's add
full 64-bit tests to lib/test_bpf and fix JITs.
I've applied the first two patches of the series.
