On 10 July 2018 at 13:23, Florian Westphal <fw@xxxxxxxxx> 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. Exactly! -- 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
