On Wed, Jun 20, 2018 at 11:32:26PM +0200, Florian Westphal wrote:
> Yi-Hung Wei and Justin Pettit found a race in the garbage collection scheme
> used by nf_conncount.
>
> When doing list walk, we lookup the tuple in the conntrack table.
> If the lookup fails we we remove this tuple from our list because
> the conntrack entry is gone.
>
> This is the common cause, but turns out its not the only one.
> The list entry could have been created just before by another cpu, i.e. the
> conntrack entry might not yet have been inserted into the global hash.
>
> The avoid this, we introduce a timestamp and the owning cpu.
> If the entry appears to be stale, evict only if:
> 1. The current cpu is the one that added the entry, or,
> 2. The timestamp is older than two jiffies
>
> The second constaint allows GC to be taken over by other
> cpu too (e.g. because a cpu was offlined or napi got moved to another
> cpu).
>
> We can't pretend the 'doubtful' entry wasn't in our list.
> Instead, when we don't find an entry indicate via IS_ERR
> that entry was removed ('did not exist' or withheld
> ('might-be-unconfirmed').
Applied, thanks Florian.
--
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
