Re: [RFC] alternative to conntrack ID

[Pablo Neira <pablo@eurodev.net>]

Patrick McHardy wrote:
> On Tue, 14 Jun 2005, Pablo Neira wrote:
> 
>>> At dumping we could use the flip-bit solution: entries which are already
>>> dumped were marked with the next value of the bit. Of course user 
>>> requests
>>> for dumping must be serialized, but conntrack replication could benefit
>>> from such schema, because new entries could be added to the conntrack
>>> table and replicated during full conntrack table replication as well.
>>
>>
>> Could you elaborate this idea about the flip-bit solution, please? 
>> looks interesting.
> 
> 
> You only allow one process to dump the table at a time, In each
> conntrack entry you flip a bit when dumping it. When continuing
> you continue with the next entry that has the bit unflipped.
> This way you don't need an ID at all. You need a timeout to make
> sure a hung process isn't blocking dumps forever. A malicious
> acting process could probably still block others for a long time,
> but dumping the conntrack table should only be possible with
> root priviliges anyway. When a dump is interrupted the state of
> the bits is inconsistent, in this case you need to reset all of
> them to a known state.

This would complicate the logic. Moreover, a top-like processing dumping 
the conntrack table every x seconds could be such "evil" process. I'm 
going to stuck on the idea of using a u64 id. It's the simpler solution 
at the moment.

--
Pablo