On Sat, Jun 06, 2020 at 03:33:14PM -0700, Linus Torvalds wrote: > On Sat, Jun 6, 2020 at 1:20 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > Please mention specific bugs and let's fix them. > > Well, Eric did mention one explicit bug, and several "looks dodgy" bugs. > > And the fact is, this isn't used. > > It's clever, and I like the concept, but it was probably a mistake to > do this as a user-mode-helper thing. > > If people really convert netfilter rules to bpf, they'll likely do so > in user space. This bpfilter thing hasn't gone anywhere, and it _has_ > caused problems. > > So Alexei, I think the burden of proof is not on Eric, but on you. > > Eric's claim is that > > (a) it has bugs (and yes, he pointed to at lelast one) the patch from March 12 ? I thought it landed long ago. Is there an issue with it? 'handling is questionable' is not very constructive. > (b) it's not doing anything useful true. > (b) it's a maintenance issue for execve, which is what Eric maintains. I'm not aware of execve issues. I don't remember being cc-ed on them. To me this 'lets remove everything' patch comes out of nowhere with a link to three month old patch as a justification. > So you can't just dismiss this, ignore the reported bug, and say > "we'll fix them". > > That only answers (a) (well, it _would_ have answered (a)., except you > actually didn't even read Eric's report of existing bugs). > > What is your answer to (b)-(c)? So far we had two attempts at converting netfilter rules to bpf. Both ended up with user space implementation and short cuts. bpf side didn't have loops and couldn't support 10k+ rules. That is what stalled the effort. imo it's a pointless corner case, but to be a true replacement people kept bringing it up as something valid. Now we have bpf iterator concept and soon bpf will be able to handle millions of rules. Also folks are also realizing that this effort has to be project managed appropriately. Will it materialize in patches tomorrow? Unlikely. Probably another 6 month at least. Also outside of netfilter conversion we've started /proc extension effort that will use the same umh facility. It won't be ready tomorrow as well, but both need umh. initrd is not an option due to operational constraints. We need a way to ship kernel tarball where bpf things are ready at boot. I suspect /proc extensions patches will land sooner. Couple month ago people used umh to do ovs->xdp translatation. It didn't land. People argued that the same thing can be achieved in user space and they were correct. So you're right that for most folks user space is the answer. But there are cases where kernel has to have these things before systemd starts.
