On Tue, Dec 10, 2024 at 10:29 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Tue, 2024-12-10 at 10:23 -0800, Alexei Starovoitov wrote: > > On Tue, Dec 10, 2024 at 2:35 AM Nick Zavaritsky <mejedi@xxxxxxxxx> wrote: > > > > > > > > > > Tail-called programs could execute any of the helpers that invalidate > > > > packet pointers. Hence, conservatively assume that each tail call > > > > invalidates packet pointers. > > > > > > Tail calls look like a clear limitation of "auto-infer packet > > > invalidation effect" approach. Correct solution requires propagating > > > effects in the dynamic callee-caller graph, unlikely to ever happen. > > > > > > I'm curious if assuming that every call to a global sub program > > > invalidates packet pointers might be an option. Does it break too many > > > programs in the wild? > > > > It might. Assuming every global prog changes pkt data is too risky, > > also it would diverge global vs static verification even further, > > which is a bad user experience. > > I assume that freplace and tail calls are used much less often than > global calls. If so, I think that some degree of inference, even with > limitations, would be convenient more often than not. > > > > From an end-user perspective, the presented solution makes debugging > > > verifier errors harder. An error message doesn't tell which call > > > invalidated pointers. Whether verifier considers a particular sub > > > program as pointer-invalidating is not revealed. I foresee exciting > > > debugging sessions. > > > > There is such a risk. > > I can do a v4 and add a line in the log each time the packet pointers > are invalidated. Such lines would be presented in verification failure > logs. (Can also print every register/stack slot where packet pointer > is invalidated, but this may be too verbose). This is something to consider for bpf-next. For bpf we need a minimal fix. So I applied as-is.
