Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote: > While we're discussing the patch, another question, about revisions: I > tested both modified and original iptables binaries on both standard > and modified kernels. It all works as expected, except for the case > where both binaries are used on a single kernel. For instance: > > iptables -A OUTPUT -m bpf --bytecode "`./nfbpf_compile RAW 'udp port > 8000'`" -j LOG > ./iptables.new -L > > Here the new binary will interpret the object as xt_bpf_match_v1, but > iptables has inserted xt_bpf_match. The same problem happens the other > way around. A new binary can be made robust to detect old structs, but > not the other way around. Specific to bpf, the existing xt_bpf code > has an unfortunate bug that it always prints at least one line of > code, even if ->bpf_program_num_elems == 0. > > I notice that other extensions also do not necessarily only extend > struct vN in vN+1. Is the above a known issue? Yes, I guess noone ever bothered to fix this. The kernel blob should contain the match/target revision number, so userspace can in fact see that 'this is bpf v42', but iirc the netfilter userspace just loads the highest userspace revision supported by the kernel (which is then different for the 2 iptables binaries). But we *could* display message like 'kernel uses revision 2 but I can only find 0 and 1' or fall back to the lower supported revision without guess-the-struct-by-size games. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
