[DTrace-devel] stressing the BPF verifier

[Kris Van Hees]

On Tue, Dec 01, 2020 at 11:29:16PM -0800, Eugene Loh wrote:
> On 12/01/2020 07:55 PM, Kris Van Hees wrote:

<< snip >>

> >> I can only have about 14 aggregations before the BPF verifier has a
> >> mental breakdown.
> > Can you elaborate a bit on the 'mental breakdown'?  What are the symptoms?
> > Is there an error report, error code, anything?
> 
> Ha, yeah, sorry.  Program runs fine with 14 aggregations, but then I add 
> a 15th and the BPF verifier spits out over 100k lines of output... 
> walking all sorts of combinations of branches (I guess, I haven't really 
> looked too closely, but I think that's what it's doing) and then in the 
> "middle" of the walk it stops reporting, saying
> dtrace: could not enable tracing: BPF program load for 'dtrace:::BEGIN' 
> failed: No space left on device
> 
> So, in dt_bpf_prog_load(), I doubled the size of the BPF log passed to 
> bpf_load_program_xattr(), and I could go from 14 aggregations to 28.  
> So, I guess I have a workaround.  Still, the BPF verifier seems rather 
> heavyweight.

Ok, so we're most likely not looking at a verifier issue but rather an
annoying limitation caused by the fact that the log buffer passed into the
verifier is of a static size.

That sounds like we may have to use a hack where we first issue the program
load without logging (thus not incurring this problem), and if the load fails,
re-ssieu it with logging enabled (and passing in a *large* buffer*).

Let's look into that after we get the current pending patch sets out of the
way.

It would be nice if a failed program load would somehow be able to let us know
just how large of a buffer it would need, but alas, that is not the case.

	Kris