On Tue, Nov 04, 2025 at 01:10:12PM +0000, Daniel P. Berrangé wrote:
> On Tue, Nov 04, 2025 at 01:37:34PM +0100, Kevin Wolf wrote:
> > Am 03.11.2025 um 21:10 hat Eric Blake geschrieben:
> > > The code had three similar repetitions of an iteration over one or all
> > > of nsiocs to set up a GSource, and likewise for teardown.  Since an
> > > upcoming patch wants to tweak whether GSource or AioContext is used,
> > > its better to consolidate that into one helper function for fewer
> > > places to edit later.
> > > 
> > > Signed-off-by: Eric Blake <[email protected]>
> > > ---
> > >  io/net-listener.c | 109 +++++++++++++++++++---------------------------
> > >  1 file changed, 45 insertions(+), 64 deletions(-)
> > 
> > > @@ -145,15 +174,11 @@ void 
> > > qio_net_listener_set_client_func_full(QIONetListener *listener,
> > >                                             GDestroyNotify notify,
> > >                                             GMainContext *context)
> > >  {
> > > -    size_t i;
> > > -
> > >      if (listener->io_func == func && listener->io_data == data) {
> > >          return;
> > >      }
> > > 
> > > -    if (listener->io_func) {
> > > -        trace_qio_net_listener_watch_disabled(listener, 
> > > "set_client_func");
> > > -    }
> > > +    qio_net_listener_unwatch(listener, "set_client_func");
> > >      if (listener->io_notify) {
> > >          listener->io_notify(listener->io_data);
> > >      }
> > 
> > This changes the order between the io_notify() call and the unwatch. Is
> > this intentional? If so, maybe mention it in the commit message and why
> > it's safe.
> 
> At least conceptually I think this ordering is better, and I don't think
> there should be any functional consequences from the change.
>

It may have been inadvertent at the time I wrote the patch, but I
agree it makes sense to call it out as intentional in v2.

Before this patch series, io_notify is typically object_unref on an
object that has other references besides the one associated with the
NetListener.  In which case, calling io_notify() reduces the refcount,
for example from 2 to 1, but has no other impact in relation to
whether the GSource is still armed.  More drastic would be if the
io_notify() reduced the refcount from 1 to 0 and thereby finalized the
data.  If the GSource is still armed and has any chance at all of a
narrow window of time where it can fire before being unwatched, but
the io_data has been freed because the io_notify() dropped the
refcount to 0 rather than merely reducing it, then the callback can
risk a use-after-free of the io_data.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org


Reply via email to