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

[Menglong Dong <menglong.dong@linux.dev>]

On 2025/10/9 04:08, Kumar Kartikeya Dwivedi wrote:
> On Wed, 8 Oct 2025 at 21:34, Eduard Zingerman <eddyz87@gmail.com> wrote:
> >
> > On Wed, 2025-10-08 at 19:08 +0200, Kumar Kartikeya Dwivedi wrote:
> > > On Wed, 8 Oct 2025 at 18:27, Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Wed, Oct 8, 2025 at 7:41 AM Leon Hwang <hffilwlqm@gmail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 2025/10/7 14:14, Menglong Dong wrote:
> > > > > > On 2025/10/2 10:03, Alexei Starovoitov wrote:
> > > > > > > On Fri, Sep 26, 2025 at 11:12 PM Menglong Dong <menglong8.dong@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Introduce the function bpf_prog_report_probe_violation(), which is used
> > > > > > > > to report the memory probe fault to the user by the BPF stderr.
> > > > > > > >
> > > > > > > > Signed-off-by: Menglong Dong <menglong.dong@linux.dev>
> > > > >
> > > > > [...]
> > > > >
[......]
> > >
> > > Yeah, agreed that this would be useful, particularly in this case. I'm
> > > wondering how we'll end up implementing this.
> > > Sounds like it needs to be tied to the program's invocation, so it
> > > cannot be per-cpu per-program, since they nest. Most likely should be
> > > backed by run_ctx, but that is unavailable in all program types. Next
> > > best thing that comes to mind is reserving some space in the stack
> > > frame at a known offset in each subprog that invokes this helper, and
> > > use that to signal (by finding the program's bp and writing to the
> > > stack), the downside being it likely becomes yet-another arch-specific
> > > thing. Any other better ideas?
> >
> > Another option is to lower probe_read to a BPF_PROBE_MEM instruction
> > and generate a special kind of exception handler, that would set r0 to
> > -EFAULT. (We don't do this already, right? Don't see anything like that
> > in verifier.c or x86/../bpf_jit_comp.c).
> >
> > This would avoid any user-visible changes and address performance
> > concern. Not so convenient for a chain of dereferences a->b->c->d,
> > though.
> 
> 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.
> Then if we expose prog_stream_dump_stack() as a kfunc (should be
> trivial), the user can write anything to stderr that is relevant to
> get more information on the fault.

Thanks for all the ideas! So we have following approaches
on this problem:

may_goto(Kumar)
--------------------------
Hmm......I haven't figure how this work on this problem yet.

"may_goto" is a condition break, does it mean that we introduce
a "condition_fault"? Will it need the supporting of the compiler?

I'm not sure if this is the right understanding: save the fault
type(PROBE_FAULT, AREA_READ_FAULT, AREA_WRITE_FAULT) to
the stack or the run_ctx, and the "if (condition_fault)" will be
replace with "if (__stack or run_ctx)".

save errno to r0(Eduard)
-----------------------------------
Save the errno to r0 in the exception handler of BPF_PROBE_MEM,
and read r0 with a __kfun in BPF program. (Not sure if I understand
it correctly).

This sounds effective, but won't this break the usage of r0? I mean,
the r0 can be used by the BPF program somewhere.

trace error event(Kumar)
------------------------------------
Call a empty and traceable function in the exception handler.

This maybe the simplest way, and I think the only shortcoming
is that there may be some noise, as the the BPF program can
receive the fault event from other BPF users.

And maybe it's better to pass the bpf prog to the arguments of
the empty function, therefore users can do some filter. Or, we
can introduce a tracepoint for this propose.

And I think this is the similar way that Leon suggested later.

bpf errno(Leon)
----------------------
introduce a percpu variable, save the -EFAULT to it in the
exception handler. Introduce the __kfunc to read, set and
clear the errno.

output the error information directly to STDERR(Menglong)
--------------------------------------------------------------------------------------
As it described.

Ah......it seems we have many approaches here, and most
of them work. Do we have any ideas on these ideas?

Thanks!
Menglong Dong

> 
> It is then up to the user to decide the rate of messages for such
> faults etc. and get more information if needed.
>