[PATCH 0/2] Clean up reset of tap connections
I ran into some mildly confusing stuff in the tap reset path while working on the epoll rework. Here's a couple of fixes for it. David Gibson (2): tap: Clean up tap reset path tap: More sensible behaviour for error on listening qemu socket tap.c | 57 ++++++++++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 25 deletions(-) -- 2.41.0
In tap_handler() if we get an error on the tap device or socket, we use
tap_sock_init() to re-initialise it. However, what we actually need for
this reset case has remarkably little in common with the case where we're
initialising for the first time:
* Re-initialising the packet pools is unnecessary
* The case of a passed in fd (--fd) isn't relevant
* We don't even call this for pasta mode
* We will never re-call tap_sock_unix_init() because we never clear
fd_tap_listen
In fact the only thing we do in tap_sock_init() relevant to the reset case
is to remove the fd from the epoll and close it... which isn't used in the
first initialisation case.
So make a new tap_sock_reset() function just for this case, and simplify
tap_sock_init() slightly as being used only for the first time case.
Signed-off-by: David Gibson
We call tap_sock_unix_new() to handle a new connection to the qemu socket
if we get an EPOLLIN event on c->fd_tap_listen. If we get an error event
on c->fd_tap_listen instead, we'll fall through to the "tap reset" path.
However, this won't do anything useful for an error on the listening
socket, it will just close the already connected socket. If we wanted to
handle errors on this socket, we'd need to do something different than for
an error on the connected socket.
So, change the logic to explicitly do nothing for any !EPOLLIN events on
the listening socket.
Signed-off-by: David Gibson
participants (1)
-
David Gibson