From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, berrange@redhat.com
Subject: Re: [PATCH 1/8] qio: Add trace points to net_listener
Date: Thu, 6 Nov 2025 13:20:17 +0100 [thread overview]
Message-ID: <aQySgdWUe1LXRNDq@redhat.com> (raw)
In-Reply-To: <ehwnhhrnfncvgqgkbqo2ejuecj7jfkowgfzsw26xbi7rt2qqdh@ajudfowin4lm>
Am 05.11.2025 um 18:18 hat Eric Blake geschrieben:
> On Tue, Nov 04, 2025 at 12:08:42PM +0100, Kevin Wolf wrote:
> > Am 03.11.2025 um 21:10 hat Eric Blake geschrieben:
> > > Upcoming patches will adjust how net_listener watches for new client
> > > connections; adding trace points now makes it easier to debug that the
> > > changes work as intended. For example, adding
> > > --trace='qio_net_listener*' to the qemu-storage-daemon command line
> > > before --nbd-server will track when the server first starts listening
> > > for clients.
> > >
> > > Signed-off-by: Eric Blake <eblake@redhat.com>
> > > ---
> > > io/net-listener.c | 17 +++++++++++++++++
> > > io/trace-events | 5 +++++
> > > 2 files changed, 22 insertions(+)
> > >
> > > diff --git a/io/net-listener.c b/io/net-listener.c
> > > index 47405965a66..0adbc409cf2 100644
> > > --- a/io/net-listener.c
> > > +++ b/io/net-listener.c
> > > @@ -23,6 +23,7 @@
> > > #include "io/dns-resolver.h"
> > > #include "qapi/error.h"
> > > #include "qemu/module.h"
> > > +#include "trace.h"
> > >
> > > QIONetListener *qio_net_listener_new(void)
> > > {
> > > @@ -50,6 +51,7 @@ static gboolean qio_net_listener_channel_func(QIOChannel *ioc,
> > > return TRUE;
> > > }
> > >
> > > + trace_qio_net_listener_callback(listener, listener->io_func);
> > > if (listener->io_func) {
> > > listener->io_func(listener, sioc, listener->io_data);
> > > }
> >
> > Not necessarily a problem, but I wonder why you decided to have the
> > trace point unconditional here...
> >
> > > @@ -143,6 +147,9 @@ void qio_net_listener_set_client_func_full(QIONetListener *listener,
> > > {
> > > size_t i;
> > >
> > > + if (listener->io_func) {
> > > + trace_qio_net_listener_watch_disabled(listener, "set_client_func");
> > > + }
> > > if (listener->io_notify) {
> > > listener->io_notify(listener->io_data);
> > > }
> >
> > ...while everywhere else you only call it with a non-NULL
> > listener->io_func.
>
> In the former, the trace is printing out the address of which io_func
> (including NULL) is currently registered when the callback is reached.
> In the case where a single NetListener registers more than one socket
> address, but the user uninstalls their callback after the first client
> to connect, it is still possible that other pending connections have
> still raced, at which point the qio_net_listener_channel_func can
> still fire on those later connections even though there is no longer
> an io_func from the user. In all the latter cases, I was merely
> tracing when state transitioned between the user installing a handler
> or removing one.
>
> Unless you think it would be to noisy, I'm game for changing this in
> v2 to have all of the traces be unconditional. It is potentially
> noisier, but also would aid in spotting how many times a client
> requests no change to the current io_func or lack thereof.
I think being noisy in traces is okay. It's easy enough to filter the
output for non-NULL instances if that's what you need. In debugging I
usually want more data, having too much data is rarely a problem.
> Also worth thinking about: in this patch, I added new traces under the
> names enabled/disabled, with the trace points being reacable from
> multiple locations. Then in 4/8, when refactoring to consolidate
> duplicate code, the trace points are reduced to a single usage in
> functions named watch/unwatch. It may be worth rethinking naming to
> have the tracepoint and function names share the same terminology.
Yes, that's a good idea.
Kevin
next prev parent reply other threads:[~2025-11-06 12:20 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 20:10 [PATCH 0/8] Fix deadlock with bdrv_open of self-served NBD Eric Blake
2025-11-03 20:10 ` [PATCH 1/8] qio: Add trace points to net_listener Eric Blake
2025-11-04 10:43 ` Daniel P. Berrangé
2025-11-04 11:08 ` Kevin Wolf
2025-11-05 17:18 ` Eric Blake
2025-11-06 12:20 ` Kevin Wolf [this message]
2025-11-03 20:10 ` [PATCH 2/8] qio: Minor optimization when callback function is unchanged Eric Blake
2025-11-04 10:44 ` Daniel P. Berrangé
2025-11-04 11:13 ` Kevin Wolf
2025-11-05 17:23 ` Eric Blake
2025-11-03 20:10 ` [PATCH 3/8] qio: Remember context of qio_net_listener_set_client_func_full Eric Blake
2025-11-04 10:50 ` Daniel P. Berrangé
2025-11-04 11:25 ` Kevin Wolf
2025-11-05 19:18 ` Eric Blake
2025-11-03 20:10 ` [PATCH 4/8] qio: Factor out helpers qio_net_listener_[un]watch Eric Blake
2025-11-04 11:03 ` Daniel P. Berrangé
2025-11-04 13:15 ` Kevin Wolf
2025-11-05 19:22 ` Eric Blake
2025-11-04 12:37 ` Kevin Wolf
2025-11-04 13:10 ` Daniel P. Berrangé
2025-11-05 19:32 ` Eric Blake
2025-11-03 20:10 ` [PATCH 5/8] qio: Let listening sockets remember their owning QIONetListener Eric Blake
2025-11-05 20:06 ` Eric Blake
2025-11-06 18:35 ` Eric Blake
2025-11-07 8:50 ` Daniel P. Berrangé
2025-11-07 13:47 ` Eric Blake
2025-11-03 20:10 ` [PATCH 6/8] qio: Hoist ref of listener outside loop Eric Blake
2025-11-04 11:13 ` Daniel P. Berrangé
2025-11-05 21:57 ` Eric Blake
2025-11-11 14:43 ` Daniel P. Berrangé
2025-11-11 15:48 ` Kevin Wolf
2025-11-11 16:07 ` Daniel P. Berrangé
2025-11-11 19:09 ` Eric Blake
2025-11-11 20:07 ` Eric Blake
2025-11-12 10:31 ` Daniel P. Berrangé
2025-11-12 10:20 ` Daniel P. Berrangé
2025-11-03 20:10 ` [PATCH 7/8] qio: Use AioContext for default-context QIONetListener Eric Blake
2025-11-04 11:37 ` Daniel P. Berrangé
2025-11-05 22:06 ` Eric Blake
2025-11-04 15:14 ` Kevin Wolf
2025-11-03 20:10 ` [PATCH 8/8] iotests: Add coverage of recent NBD qio deadlock fix Eric Blake
2025-11-04 11:38 ` Vladimir Sementsov-Ogievskiy
2025-11-05 22:10 ` Eric Blake
2025-11-06 8:20 ` Vladimir Sementsov-Ogievskiy
2025-11-06 12:26 ` Kevin Wolf
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=aQySgdWUe1LXRNDq@redhat.com \
--to=kwolf@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.