Re: [PATCH] for some issues in tcp window tracking patch

[Patrick McHardy <kaber@trash.net>]

Henrik Nordstrom wrote:
> On Fri, 21 May 2004, Patrick McHardy wrote:
> 
> 
>>I missed that question. It's probably not neccessary, we will get a
>>small race when zapping conntracks, but according to this comment in
>>unreplied() we already have one anyway.
> 
> 
> What I thought.. a __set_bit should be sufficient here, right?

I think so.

> 
> Is there any good description somewhere on how these memory barriers 
> works and when they are needed, or more precisely what is the difference 
> between set_bit and __set_bit in terms of when/how/why each should be 
> used?

Judging from the comments, the difference is that set_bit guarantees
multiple set_bits will be seen by all processors in the right order.
atomic is not the right word, since a single load or store is
indivisible on x86 anyway. The reason why one would use __set_bit
instead of just ORing the bits together is that it can operate on
almost arbitrarily large bitmaps.

> 
> But in this case there is many races.. a test_bit followed  by a set_bit 
> is not atomic unles governed by a surrounding lock independent of if 
> there is memory barriers of not around the operations, and the flushing of 
> unconfirmed sessions is inherently racy anyway without strict locking. If 
> there is strict locking then memory barriers in the set_bit should be 
> completely irrelevant. Right?

Yes.

Regards
Patrick

> 
> Regards
> Henrik
>