From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56257)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <namei.unix@gmail.com>) id 1TugM5-0002Yf-OH
	for qemu-devel@nongnu.org; Mon, 14 Jan 2013 04:29:28 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <namei.unix@gmail.com>) id 1TugLy-0005un-3u
	for qemu-devel@nongnu.org; Mon, 14 Jan 2013 04:29:21 -0500
Received: from mail-pa0-f43.google.com ([209.85.220.43]:58214)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <namei.unix@gmail.com>) id 1TugLx-0005tp-T7
	for qemu-devel@nongnu.org; Mon, 14 Jan 2013 04:29:14 -0500
Received: by mail-pa0-f43.google.com with SMTP id fb10so2135009pad.16
	for <qemu-devel@nongnu.org>; Mon, 14 Jan 2013 01:29:13 -0800 (PST)
Message-ID: <50F3CFDD.2000003@gmail.com>
Date: Mon, 14 Jan 2013 17:29:01 +0800
From: Liu Yuan <namei.unix@gmail.com>
MIME-Version: 1.0
References: <50F3BEE2.5090802@gmail.com> <50F3CB54.6080506@redhat.com>
In-Reply-To: <50F3CB54.6080506@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] 100% CPU when sockfd is half-closed and unexpected
 behavior for qemu_co_send()
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

On 01/14/2013 05:09 PM, Paolo Bonzini wrote:
>> Another unexpected behavior is that qemu_co_send() will send data
>> > successfully for the half-closed situation, even the other end is
>> > completely down. I think the *expected* behavior is that we get notified
>> > by a HUP and close the affected sockfd, then qemu_co_send() will not
>> > send any data, then the caller of qemu_co_send() can handle error case.
> qemu_co_send() should get an EPIPE or similar error.  The first time it
> will report a partial send, the second time it will report the error
> directly to the caller.
> 
> Please check if this isn't a bug in the Sheepdog driver.

I don't think so. I use netstat to assure that the connection is in closed_wait state and I added a printf in the qemu_co_send() and it indeed sent successfully, this can be backed by the Linux kernel source code:

static ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset,
                                size_t size, int flags)
{
         ....
        /* Wait for a connection to finish. One exception is TCP Fast Open
         * (passive side) where data is allowed to be sent before a connection
         * is fully established.
         */
        if (((1 << sk->sk_state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) &&
            !tcp_passive_fastopen(sk)) {
                if ((err = sk_stream_wait_connect(sk, &timeo)) != 0)
                        goto out_err;
        }
        ....
}

which will put data in the sock buf and returns successful in a CLOSED_WAIT state. I don't see means in Sheepdog driver code to get a HUP notification for a actual cut off connection.

Thanks,
Yuan