On Tue, Dec 10, 2024 at 10:52 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Tue, 2024-12-10 at 10:31 -0800, Alexei Starovoitov wrote: > > [...] > > > > > > 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. > > I must admit, I'm not familiar with the way bpf/bpf-next interact. > Should I wait for certain merges to happen before posting a patch > to bpf-next? bpf tree is for fixes only. We typically send PR every week. Once it lands in Linus's tree we merge the fixes into bpf-next. At that time follows up can be send targeting bpf-next.