Re: [PATCH 3/3][CONNTRACK] Fix race condition in early drop

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
>>Pablo Neira Ayuso wrote:
>>
>>>>How about incrementing {ip,nf}_conntrack_count at first ?
>>>>
>>>>    1. atomic_add()
>>>>    2. if {ip,nf}_conntrack_count > {ip,nf}_conntrack_max (not '>=' )
>>>>       then early_drop()
>>>>    3. if early_drop() failed, atomic_dec()
>>>
>>>
>>>I thought about this possibility but then we can't guarantee the fixed 
>>>maximum number of conntracks in the system.
>>
>>Hm, actually this is wrong, we can guarantee the maximum number but 
>>aren't we somehow fooling the counter? I mean, the counter can reach 
>>values higher than conntrack_max during a short period.
> 
> 
> good point. I don't mind fooling the counter in this short period,


Me neither. We can already be off by more than one since early_drop
just removes a conntrack from the hash tables, but it is not necessarily
destroyed immediately (at which point the counter is decremented).
This is a reason why we can't loop while waiting for the counter to
decrement.