Thread (22 messages) read the whole thread 22 messages, 6 authors, 2025-10-11

Re: bpf_errno. Was: [PATCH RFC bpf-next 1/3] bpf: report probe fault to BPF stderr

From: Leon Hwang <hidden>
Date: 2025-10-09 15:15:47
Also in: bpf, lkml

quoted
Since we're piling on ideas, one of the other things that I think
could be useful in general (and maybe should be done orthogonally to
bpf_errno)
is making some empty nop function and making it not traceable reliably
across arches and invoke it in the bpf exception handler.
No new traceable function is needed, since ex_handler_bpf itself can
already be traced via fentry.

If users really want to detect whether a fault occurred, they could
attach a program to ex_handler_bpf and record fault events into a map.
However, this approach would be too heavyweight just to check for a
simple fault condition.
As ex_handler_bpf can already be traced using fentry, a potential
approach without modifying the kernel would be:

1. In the fentry program:

int is_fault SEC(".percpu.fault");

SEC("fentry/ex_handler_bpf")
int BPF_PROG(f__ex, const struct exception_table_entry *x, struct
pt_regs *regs)
{
    is_fault = 1;
    return 0;
}

2. In the main program:

int is_fault SEC(".percpu.fault");

is_fault = 0;
/* probe read */
if (is_fault)
    /* handle fault */;

The main idea is that both programs share the same ".percpu.fault" map,
so the variable 'is_fault' can be accessed from both sides.

Here, ".percpu.fault" represents a percpu_array map section, which is
expected to be supported in the future.
In the meantime, it can simply be replaced with a regular percpu_array map.

Finally, this approach is conceptually similar to the idea of using a
global errno.

Thanks,
Leon
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help