On Fri, Sep 6, 2024 at 3:23 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Thu, 5 Sep 2024 17:26:42 -0700 Alexei Starovoitov wrote: > > Yes, it's a bit of a whack a mole and eventually we can get rid of it > > with a smarter verifier (likely) or smarter objtool (unlikely). > > Long term we should be able to analyze body of TP_fast_assign > > automatically and conclude whether it's handling NULL for pointer > > arguments or not. bpf verifier can easily do it for bpf code. > > We just need to compile TP_fast_assign() as a tiny bpf snippet. > > This is work in progress. > > Can we not wait for that work to conclude, then? AFAIU this whole > patch set is just a minor quality of life improvement for BPF progs > at the expense of carrying questionable changes upstream. > I don't see the urgency. The urgency is now because the situation is dire. The verifier assumes that skb is not null and will remove if (!skb) check assuming that it's a dead code. This patch set adds trusted stuff and fixes this issue too which is the more important part. Also it's not clear how long it will take to do 'dual compile'. It's showing promise atm, but timelines are not certain. If you recall I pushed for 'dual compile' for the last several years and only now we found time to work on it.
