public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 1/5] tap: Better report errors receiving from QEMU socket
Date: Fri, 26 Jul 2024 13:25:08 +0200	[thread overview]
Message-ID: <20240726132508.6a4d1147@elisabeth> (raw)
In-Reply-To: <20240726072031.3941305-2-david@gibson.dropbear.id.au>

On Fri, 26 Jul 2024 17:20:27 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> If we get an error on recv() from the QEMU socket, we currently don't
> print any kind of error.  Although this can happen in a non-fatal situation
> such as a guest restarting, it's unusual enough that we realy should report
> something for debugability.
> 
> Add an error message in this case.  Also always report when the qemu
> connection closes for any reason, not just when it will cause us to exit
> (--one-off).
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  tap.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/tap.c b/tap.c
> index 44bd4445..a2ae7c2a 100644
> --- a/tap.c
> +++ b/tap.c
> @@ -969,10 +969,10 @@ void tap_add_packet(struct ctx *c, ssize_t l2len, char *p)
>   */
>  static void tap_sock_reset(struct ctx *c)
>  {
> -	if (c->one_off) {
> -		info("Client closed connection, exiting");
> +	info("Client connection closed%s", c->one_off ? ", exiting" : "");
> +
> +	if (c->one_off)
>  		exit(EXIT_SUCCESS);
> -	}
>  
>  	/* Close the connected socket, wait for a new connection */
>  	epoll_ctl(c->epollfd, EPOLL_CTL_DEL, c->fd_tap, NULL);
> @@ -1005,8 +1005,10 @@ redo:
>  
>  	n = recv(c->fd_tap, p, TAP_BUF_FILL, MSG_DONTWAIT);
>  	if (n < 0) {
> -		if (errno != EINTR && errno != EAGAIN && errno != EWOULDBLOCK)
> +		if (errno != EINTR && errno != EAGAIN && errno != EWOULDBLOCK) {
> +			err_perror("Error receiving from QEMU socket");

Nit I'm fixing up on merge: it's not necessarily QEMU, because libkrun
and perhaps others also use this path (in fact, the whole problem was
reported as part of the libkrun integration).

Maybe it's obvious to users anyway, but this might seriously confuse
somebody who's using e.g. krun on Asahi Linux (is QEMU running, one
might wonder):
  https://github.com/slp/krun#motivation
  https://github.com/slp/krun/blob/main/crates/krun/src/net.rs

On top of that, now that we have an error message, I guess it would be
nice to state we're resetting the connection, because it's not really
obvious: the subsequent message from tap_sock_reset() makes it look like
the client decided to close the connection on its own.

So I'm changing this to:

			err("Error receiving from guest, resetting connection");

...if you see an issue with it, I'll send another patch.

-- 
Stefano


  reply	other threads:[~2024-07-26 11:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-26  7:20 [PATCH 0/5] Fix assorted errors in the Qemu socket tap receive handler David Gibson
2024-07-26  7:20 ` [PATCH 1/5] tap: Better report errors receiving from QEMU socket David Gibson
2024-07-26 11:25   ` Stefano Brivio [this message]
2024-07-26 11:50     ` Stefano Brivio
2024-07-26 12:02     ` David Gibson
2024-07-26  7:20 ` [PATCH 2/5] tap: Don't attempt to carry on if we get a bad frame length from qemu David Gibson
2024-07-26 11:26   ` Stefano Brivio
2024-07-26  7:20 ` [PATCH 3/5] tap: Don't use EPOLLET on Qemu sockets David Gibson
2024-07-26  8:00   ` Stefano Brivio
2024-07-26 10:44     ` Stefano Brivio
2024-07-26 12:12     ` David Gibson
2024-07-26 13:25       ` Stefano Brivio
2024-07-29  1:15         ` David Gibson
2024-07-26  7:20 ` [PATCH 4/5] tap: Correctly handle frames of odd length David Gibson
2024-07-26  7:20 ` [PATCH 5/5] tap: Improve handling of partially received frames on qemu socket David Gibson
2024-07-26 11:39   ` Stefano Brivio
2024-07-26 12:33     ` David Gibson
2024-07-26 13:19 ` [PATCH 0/5] Fix assorted errors in the Qemu socket tap receive handler Stefano Brivio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240726132508.6a4d1147@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).