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.
At allocation time we do not know what kind of NAT transformations
will be applied by the ruleset, i.e. we'd need another locking step to
move the entries to the right location in the hash table.
Same if the skb is dropped: we need to lock the conntrack table again to
delete the newly added entry -- this isn't needed right now because the
conntrack is only on the percpu unconfirmed list in this case.
This is also a problem because of conntrack events, we would have to
seperate insertion and notification, else we'd flood userspace for every
conntrack we create in case of a packet drop flood.
Other solutions are:
1. use a ruleset that assigns the same nat mapping for both A and AAAA
requests, or,
2. steer all packets that might have this problem (i.e. udp dport 53) to
the same cpu core.
Yet another solution would be a variation of this patch set:
1. Only add the reply direction to the table (i.e. conntrack -L won't show
the duplicated entry).
2. Add a new conntrack flag for the duplicate that guarantees the
conntrack is removed immediately when first reply packet comes in.
This would also have the effect that the conntrack can never be
assured, i.e. the "hidden duplicates" are always early-dropable if
conntrack table gets full.
3. change event code to never report such duplicates to userspace.
