> -----Original Message----- > From: Eduardo Otubo [mailto:ot...@redhat.com] > Sent: 20 November 2017 10:41 > To: xen-de...@lists.xenproject.org > Cc: net...@vger.kernel.org; Paul Durrant <paul.durr...@citrix.com>; Wei > Liu <wei.l...@citrix.com>; linux-ker...@vger.kernel.org; > vkuzn...@redhat.com; cav...@redhat.com; che...@redhat.com; > mga...@redhat.com; Eduardo Otubo <ot...@redhat.com> > Subject: [PATCH] xen-netfront: remove warning when unloading module > > When unloading module xen_netfront from guest, dmesg would output > warning messages like below: > > [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! > [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) > > This problem relies on netfront and netback being out of sync. By the time > netfront revokes the g.e.'s netback didn't have enough time to free all of > them, hence displaying the warnings on dmesg. > > The trick here is to make netfront to wait until netback frees all the g.e.'s > and only then continue to cleanup for the module removal, and this is done > by > manipulating both device states. > > Signed-off-by: Eduardo Otubo <ot...@redhat.com> > --- > drivers/net/xen-netfront.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c > index 8b8689c6d887..b948e2a1ce40 100644 > --- a/drivers/net/xen-netfront.c > +++ b/drivers/net/xen-netfront.c > @@ -2130,6 +2130,17 @@ static int xennet_remove(struct xenbus_device > *dev) > > dev_dbg(&dev->dev, "%s\n", dev->nodename); > > + xenbus_switch_state(dev, XenbusStateClosing); > + while (xenbus_read_driver_state(dev->otherend) != > XenbusStateClosing){ > + cpu_relax(); > + schedule(); > + } > + xenbus_switch_state(dev, XenbusStateClosed); > + while (dev->xenbus_state != XenbusStateClosed){ > + cpu_relax(); > + schedule(); > + } > +
Waitiing for closing should be ok but waiting for closed is risky. As soon as a backend is in the closed state then a toolstack can completely remove the backend xenstore area, resulting a state of XenbusStateUnknown, which would cause your second loop to spin forever. Paul > xennet_disconnect_backend(info); > > unregister_netdev(info->netdev); > -- > 2.13.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
