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/10 20:05, Menglong Dong wrote:
> 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.

I think I'm a little understand it:

int a, *b;

b = xxx;
a = *b; // insert "r0 = 0" before this insn in verifier
             // if fault happen, r0 will become -EFAULT
if (bpf_probe_fault()) // change it to if (r0) in verifier
   return;

Am I right?

Thanks!
Menglong Dong

> 
> 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.
> > 
> 
> 
> 
> 
> 
>