Eric Woudstra <[email protected]> wrote: > >> + return NF_ACCEPT; > > > > > > Hmm. I'm not sure, I think this should either drop them right away > > OR pass them to do_chain without any changes (i.e. retain existing > > behavior and have this be same as nft_set_pktinfo_unspec()). > > > > but please wait until resend. > > > > I hope to finish a larger set i've been working on by tomorrow. > > Then I can give this a more thorough review (and also make a summary + > > suggestion wrt. the bridge match semantics wrt. vlan + pppoe etc. > > > > My hunch is that your approach is pretty much the way to go > > but I need to complete related homework to make sure I did not > > miss/forget anything. > > I understand. I've send this, because from v5 to v15 it moved towards > matching in the rule, but it all started with the fact that > nft_flow_offload_eval() uses nft_thoff(). > > At a bare minimum I need to address having pkt->thoff set correctly to > implement the software bridge-fastpath.
Sorry, fail to see how thats related. If the header is incomplete, then with your approach the packet isn't even seen by nft_flow_offload_eval() (-> NF_ACCEPT'd). Whats the problem with passing the skb to nft_do_chain in its 'original' form?
