Thread (13 messages) 13 messages, 4 authors, 2025-12-06

Re: [PATCH bpf v1 1/2] bpf: cpumap: propagate underlying error in cpu_map_update_elem()

From: Kohei Enju <hidden>
Date: 2025-12-06 07:31:15
Also in: bpf

On Wed, 03 Dec 2025 13:31:29 +0100, Toke Høiland-Jørgensen wrote:
Jesper Dangaard Brouer [off-list ref] writes:
quoted
On 03/12/2025 11.40, Kohei Enju wrote:
quoted
On Tue, 2 Dec 2025 17:08:32 -0800, Alexei Starovoitov wrote:
quoted
On Fri, Nov 28, 2025 at 8:05 AM Kohei Enju [off-list ref] wrote:
quoted
After commit 9216477449f3 ("bpf: cpumap: Add the possibility to attach
an eBPF program to cpumap"), __cpu_map_entry_alloc() may fail with
errors other than -ENOMEM, such as -EBADF or -EINVAL.

However, __cpu_map_entry_alloc() returns NULL on all failures, and
cpu_map_update_elem() unconditionally converts this NULL into -ENOMEM.
As a result, user space always receives -ENOMEM regardless of the actual
underlying error.

Examples of unexpected behavior:
   - Nonexistent fd  : -ENOMEM (should be -EBADF)
   - Non-BPF fd      : -ENOMEM (should be -EINVAL)
   - Bad attach type : -ENOMEM (should be -EINVAL)

Change __cpu_map_entry_alloc() to return ERR_PTR(err) instead of NULL
and have cpu_map_update_elem() propagate this error.

Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap")
The current behavior is what it is. It's not a bug and
this patch is not a fix. It's probably an ok improvement,
but since it changes user visible behavior we have to be careful.
Oops, got it.
When I resend, I'll remove the tag and send to bpf-next, not to bpf.

Thank you for taking a look.
quoted
I'd like Jesper and/or other cpumap experts to confirm that it's ok.
Sure, I'd like to wait for reactions from cpumap experts.
Skimmed the code changes[1] and they look good to me :-)
We have one example of a use of the cpumap programs in xdp-tools, and
there we just report the error message to the user. I would guess other
apps would follow the same pattern rather than react to a specific error
code; especially since there's only one error code being used here.

So I agree, this should be OK to change.

-Toke
Thank you for the clarification, Toke and Jesper.
Since I see no objections so far, I'll work on v2 and resend next week.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help