Besides xenbus driver bug, the problem is that there will be a deadlock if the
Now I have recognized where the deadlock comes if the child thread (read_thread
in xs.c) exists. After the child thread dies, the main thread (read_reply in
xs.c) will go on. So in the following invocation of read_reply (no reading
thread exists now), read_reply will use read_message(h) == -1 to read the
reply. If the reply is XS_WATCH_EVENT type, the read_message function returns
zero but leaves the reply_list empty, so read_reply goes to
condvar_wait(&h->reply_condvar, &h->reply_mutex, h) since the reply_list is
empty. The problem incurs here. Since condvar_wait is a different definition
when using PTHREAD to read reply message, it will just wait on this signal, do
This is one possibility of deadlocks. You can replay this bug by commenting
read_message function in the read_thread, just letting the read_thread die
directly. In this case, the reading thread does nothing.
I am not sure I have a good solution to fix this problem now. Maybe we can let
the read_message function returns a different value when the reply is
XS_WATCH_EVENT, and the read_reply function checks. If it is XS_WATCH_EVENT
type, call the read_message again.
Citrix Systems UK
From: Jeremy Fitzhardinge [jeremy@xxxxxxxx]
Sent: Thursday, August 26, 2010 12:34 PM
To: Jun Zhu (Intern)
Subject: Re: [Xen-devel] A bug in Xenbus driver
On 08/26/2010 01:25 AM, Jun Zhu (Intern) wrote:
> Sorry for my description. "Does not report correctly" is not the problem of
> xenbus read.
> I mean that in the xenstore/xs.c code, when using another thread (#ifdef
> USE_PTHREAD) to receive responses from xenbus, if this thread exits
> incorrectly, the listener should be noticed, or the listener will wait for
> response for ever.
How does that relate to your proposed fix?
Xen-devel mailing list