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). [...]
