On Tue, Jul 10, 2018 at 01:23:01PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > I see, so this is just solving the conflict for a specific usecase > > with NAT in place, ie. get_unique_tuple() returns same tuple... > > > > But how so? With NAT in place, the packet losing race will eventually > > get a different tuple, given the tuple that the first packet is using > > would be already in use. > > > > Do you have any other out-of-tree patch on top of this? > > > > Or maybe I am missing anything? :-) > > AFAIU its locally running (threaded) process, so both skbs have > non-confirmed conntracks. > > Thus, get_unique_tuple() can have high chance of not finding > reverse tuple in the conntrack table because the clashing one is > also not in global hash yet. Ah I see, it's indeed different scenario than the one I fixed for nfqueue. OK, I'm going to request some minor changes to this patch and we move on. Thanks! -- 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
