Re: [Qemu-devel] 100% CPU when sockfd is half-closed and unexpected behavior for qemu_co_send()

[Liu Yuan]

On 01/14/2013 06:23 PM, Stefan Hajnoczi wrote:
> On Mon, Jan 14, 2013 at 04:16:34PM +0800, Liu Yuan wrote:
>> Hi List,
>>   This problem can be reproduced by:
>>   1. start a sheepdog cluster and create a volume 'test'*
>>   2. attach 'test' to a bootable image like
>>      $ qemu -hda image -drive if=virtio,file=sheepdog:test
>>   3. pkill sheep # create a half-closed situation
>>
>> I have straced it that QEMU is busy doing nonsense read/write() after
>> select() in os_host_main_loop_wait(). I have no knowledge of
>> glib_select_xxx, so someone please help fix it.
> 
> You mentioned a nonsense read().  What is the return value?
> 
> If you get a read with return value 0, this tells you the socket has
> been closed.  Can you handle these cases in block/sheepdog.c?
> 

This is what I saw repeatedly:

select(25, [3 4 5 8 9 10 13 18 19 24], [], [], {1, 0}) = 2 (in [5 13],
left {0, 999994})
read(5, "\6\0\0\0\0\0\0\0", 16)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
....

5 isn't a sockfd that sheepdog uses.

I don't know if I can handle it in sheepdog.c because I noticed that
there isn't any function called when this happens. So I suspect this
should be handle at upper block core.

Thanks,
Yuan