lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] xen-netfront: remove warning when unloading module
Date
> -----Original Message-----
> From: Eduardo Otubo [mailto:otubo@redhat.com]
> Sent: 20 November 2017 10:41
> To: xen-devel@lists.xenproject.org
> Cc: netdev@vger.kernel.org; Paul Durrant <Paul.Durrant@citrix.com>; Wei
> Liu <wei.liu2@citrix.com>; linux-kernel@vger.kernel.org;
> vkuznets@redhat.com; cavery@redhat.com; cheshi@redhat.com;
> mgamal@redhat.com; Eduardo Otubo <otubo@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 <otubo@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

\
 
 \ /
  Last update: 2017-11-20 12:05    [W:0.073 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site