From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47821)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1b4iWg-0002Pj-OZ
	for qemu-devel@nongnu.org; Mon, 23 May 2016 01:35:39 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1b4iWd-0006vb-Cs
	for qemu-devel@nongnu.org; Mon, 23 May 2016 01:35:38 -0400
Received: from out2-smtp.messagingengine.com ([66.111.4.26]:45937)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1b4iWa-0006uS-W7
	for qemu-devel@nongnu.org; Mon, 23 May 2016 01:35:35 -0400
Date: Mon, 23 May 2016 01:35:26 -0400
From: "Emilio G. Cota" <cota@braap.org>
Message-ID: <20160523053526.GA15386@flamenco>
References: <1463196873-17737-1-git-send-email-cota@braap.org>
	<1463196873-17737-13-git-send-email-cota@braap.org>
	<573F8C00.7080701@gmail.com> <20160521024811.GA29744@flamenco>
	<20160521174147.GA16040@flamenco> <871t4uh66g.fsf@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <871t4uh66g.fsf@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v5 12/18] qht: QEMU's fast,
 resizable and scalable Hash Table
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex =?iso-8859-1?Q?Benn=E9e?= <alex.bennee@linaro.org>
Cc: Sergey Fedorov <serge.fdrv@gmail.com>, QEMU Developers <qemu-devel@nongnu.org>, MTTCG Devel <mttcg@listserver.greensocs.com>, Paolo Bonzini <pbonzini@redhat.com>, Peter Crosthwaite <crosthwaite.peter@gmail.com>, Richard Henderson <rth@twiddle.net>

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