Re: [Qemu-devel] [PATCH v5 12/18] qht: QEMU's fast, resizable and scalable Hash Table

["Emilio G. Cota" <cota@braap.org>]

On Sun, May 22, 2016 at 09:01:59 +0100, Alex Bennée wrote:
> Emilio G. Cota <cota@braap.org> writes:
> > A small update: I just got rid of all the atomic_read/set's that
> > apply to the hashes, since retries will take care of possible races.
> 
> I guess the potential hash-clash from a partially read or set hash is
> handled by the eventual compare against a always valid pointer?

As long as we call the cmp function with a non-NULL pointer,
we're safe. Given that pointers are read and set atomically, the
'if (p)' check before calling the cmp function guarantees that we
won't cause a segfault. This also means that items removed from
the hash table must be freed after an RCU grace period, since readers
might still see the pointers and pass them to the cmp function.
I'll document this.

If there's a reader concurrent with a writer, it's possible that
the reader might read a partially-updated hash. That's fine because
the reader will retry anyway until it can see the effect
of the writer calling seqlock_write_end. The only important
concern here is to make sure the pointers are read/set atomically.

		Emilio