The point I am clarifying is that with NFQUEUE working on the system. After resolving clashing using 71d8c47fc6537, it may result to two skb holding the same conntrack on different core traveling in the netfilter just like the nfqueue + multicast case. Chieh-Min Wang <chiehmin18@xxxxxxxxx> 於 2019年1月28日 週一 下午10:16寫道： > > Yes, I understand the cases are different. > > However, the result after resolving clashing will cause two skb point > to the same conntrack. > The first skb with confirmed conntrack may not pass through the NAT > when the second skb resolve clashing? > > Florian Westphal <fw@xxxxxxxxx> 於 2019年1月28日 週一 下午10:13寫道： > > > > Chieh-Min Wang <chiehmin18@xxxxxxxxx> wrote: > > > I think 71d8c47fc653711c4(netfilter: conntrack: introduce clash > > > resolution on insertion race) is doing the same logic for resolving > > > conntrack clashing. > > > > No, that commit dealsl with the case where two skbs have different > > conntrack objects but where tuples are the same. > > > > In nfqueue+bridge flood case the skbs point to the same conntrack > > object. > > > > Maybe one way to fix this would be to let nfqueue perform a deep > > copy of skb->_nfct in case conntrack is unconfirmed and skb_shared() > > is true. > > > > But that would of course cause drop for l4 protocols that do not support > > clash resolution. > >
