qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] tap: avoid deadlocking rx


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] tap: avoid deadlocking rx
Date: Tue, 11 Mar 2014 13:25:14 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Mar 08, 2014 at 04:00:43PM +0100, Stefan Hajnoczi wrote:
> The net subsystem has a control flow mechanism so peer NetClientStates
> can tell each other to stop sending packets.  This is used to stop
> monitoring the tap file descriptor for incoming packets if the guest rx
> ring has no spare buffers.
> 
> There is a corner case when tap_can_send() is true at the beginning of
> an event loop iteration but becomes false before the tap_send() fd
> handler is invoked.
> 
> tap_send() will read the packet from the tap file descriptor and attempt
> to send it.  The net queue will hold on to the packet and return 0,
> indicating that further I/O is not possible.  tap then stops monitoring
> the file descriptor for reads.
> 
> This is unlike the normal case where tap_can_send() is the same before
> and during the event loop iteration.  The event loop would simply not
> monitor the file descriptor if tap_can_send() returns true.  Upon next
> iteration it would check tap_can_send() again and begin monitoring if we
> can send.
> 
> The deadlock happens because tap_send() explicitly disabled read_poll.
> This is done with the expectation that the peer will call
> qemu_net_queue_flush().  But hw/net/virtio-net.c does not monitor
> vm_running transitions and issue the flush.  Hence we're left with a
> broken tap device.
> 
> Cc: address@hidden
> Reported-by: Neil Skrypuch <address@hidden>
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
>  net/tap.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Applied to my net tree:
https://github.com/stefanha/qemu/commits/net

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]