Re: [PATCH 2/2] netfilter: ipset: Fix data race between add and dump in all hash types

[Florian Westphal <fw@strlen.de>]

Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> limit the searching range for existing elements (which might be timed out 
> as well). So until the "size" is unchanged (no growing/shrinking), the 
> worst things which can happen if it's not "correct":
> 
> - new element added but dump/test don't "find" it
> - element deleted but dump/test find it
> 
> The critical part is when "size" changes. But "size" never updated 
> directly: a completely new bucket is created when growing/shrinking and 
> the new bucket is assigned via RCU mechanism.
> 
> So why do you thing the helpers are required to read/update the "pos" 
> element of the hash bucket? I might not see the wood for the trees.

As-is it is confusing. Pos is updated concurrently to dumpers
with no ordering and no annotations (READ_ONCE, WRITE_ONCE).

Maybe they are not required, but then there should be WRITE_ONCE()
and READ_ONCE and a comment explaining that this is deliberately racy.

Basically what you wrote above.  It would help to understand what
guarantees there are and that this is good enough.

As-is KCSAN will surely splat without data race annotations.