Hast locking up under 9.2

Mikolaj Golub to.my.trociny at gmail.com
Mon Nov 25 09:46:19 UTC 2013


On Mon, Nov 25, 2013 at 09:32:23AM +0100, Pawel Jakub Dawidek wrote:
> On Sat, Nov 23, 2013 at 11:59:51PM +0200, Mikolaj Golub wrote:
> > On Fri, Nov 22, 2013 at 11:18:29AM +0000, Pete French wrote:
> > 
> > > "Assertion failed: (!hio->hio_done), function write_complete, file
> > >  /usr/src/sbin/hastd/primary.c, line 1130."
> > 
> > It looks like write_complete usage (which should be called once per
> > write request) for memsync is racy.
> > 
> > Consider the following scenario:
> > 
> > 1) remote_recv_thread: memsync ack received, refcount -> 2;
> > 2) local_send_thread: local write completed, refcount -> 1, entering
> >    write_complete()
> > 3) remote_recv_thread: memsync fin received, refcount -> 0, move hio
> >    to done queue, ggate_send_thread gets the hio, checks for
> >    !hio->hio_done and (if loca_send_thread is still in
> >    write_complete()) entering write_complete()
> 
> I don't see how is that possible. The write_complete() function is
> called only when hio_countdown goes from 2 to 1 and because this is
> atomic operation it can only happen in one thread. Can you elaborate on
> how calling write_complete() concurrently for the same request is
> possible?

Yes, hio_countdown protects calling write_complete() concurently by
"component" threads. But it may also be called by ggate_send_thread():

	if (!hio->hio_done)
		write_complete(res, hio);

So if write_complete() has already started executing in
local_send_thread(), and at that time memsync fin is received, the
request is moved to ggate_send_thread, and write_complete can be
reentered if it is still in progress in local_send_thread (hio_done is
set on exiting write_complete).

That is why statement (3) in my patch: write_complete() in component
threads is called only before releasing hio_countdown. Otherwise you
are not protected from running it simultaneously by ggate_send_thread,
or even hio be moved to free before write_complete is finished in
local_send_thread. And so hio_countdown can't be used for detecting
the current memsync state.

-- 
Mikolaj Golub


More information about the freebsd-stable mailing list