Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Tue, Jan 14, 2020 at 12:53:09AM +0100, Florian Westphal wrote: > > Florian Westphal <fw@xxxxxxxxx> wrote: > > > This entire series isn't nice but so far I did not find a better > > > solution. > > > > I did consider getting rid of the unconfirmed list, but this is also > > problematic. > > Another proposal: > > I think the percpu unconfirmed list should become a hashtable. > > From resolve_normal_ct(), if __nf_conntrack_find_get() returns NULL, > this can fall back to make a rcu lookless lookup on the unconfirmed > hashtable. Unconfirmed entries can't be processed in parallel. I.e., we can detect the race (there is an unconfirmed entry in the unconfirmed table matching original tuple), but we can't do anything about it until that result has been confirmed. We could allow processing unconfirmed entries in parallel but it will require taking ct->lock in all places that add/change extensions. And we would need to do so unconditionally. At this point I'm considering to send patches to iptables and kernel that document that -m statistics can't be used for udp NAT and another patch to add a l4 hash mode to -m cluster, I don't like this series either and all alternatives are even worse.
