[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] rpc: ensure the value of nrequests for client not to be negative

On 08/25/2011 11:36 PM, Daniel P. Berrange wrote:
On Thu, Aug 25, 2011 at 10:07:36PM +0800, Guannan Ren wrote:
The value of nrequests should always be zero or positive
but in the case of stream, when error occurrs, it could be negative
and makes the client socket fd neither writable nor readable. The
case will lead to hang on libvirt client side.
This patch aim to fix the problem.
What is the scenario you use to demonstrate the original problem ?

IMHO the fix below is not right, because it is merely patching
up the problems caused by the bug, rather than actually fixing
the bug.

    The scenarios is just like the python scripts did, sometimes maybe
we need to monitor and control the stream all the time without quit on the client side, other than quit like what libvirt-client did when guest was off. So I think libvirtd should
    support it.

    According the log and code, I noticed when the guest is shutting down,
on the server side, the libvirtd will receive two messages from the pty opened fd, one is the null string, the other is an error message.(sometime, only null string, without error message the case happened on one of boxes ). The null string is with
    type VIR_NET_STREAM and status VIR_NET_CONTINUE, but the error message
is of type VIR_NET_STREAM and status VIR_NET_ERROR that this will lead to client->nrequests-- in virNetServerClientDispatchWrite(). so when the guest shut down at the second time, the value of nrequests will become -1 on the assumption that only one thread connecting on client side at that time. The negative value will pass over the value assignment to client->rx and
    lead the mode of socket fd to zero, the client side hangs.

One the libvirt-client side, when it meets the null string, it calls virConsoleShutdown()
    then quit and ignore the error message.

I don't know if it is reasonable to fix the problem, any idea is appreciated.

    Guannan Ren

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]