lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Nov 2017 10:55:55 +0000
From:   Paul Durrant <Paul.Durrant@...rix.com>
To:     'Eduardo Otubo' <otubo@...hat.com>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Wei Liu <wei.liu2@...rix.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "cavery@...hat.com" <cavery@...hat.com>,
        "cheshi@...hat.com" <cheshi@...hat.com>,
        "mgamal@...hat.com" <mgamal@...hat.com>
Subject: RE: [PATCH] xen-netfront: remove warning when unloading module

> -----Original Message-----
> From: Eduardo Otubo [mailto:otubo@...hat.com]
> Sent: 20 November 2017 10:41
> To: xen-devel@...ts.xenproject.org
> Cc: netdev@...r.kernel.org; Paul Durrant <Paul.Durrant@...rix.com>; Wei
> Liu <wei.liu2@...rix.com>; linux-kernel@...r.kernel.org;
> vkuznets@...hat.com; cavery@...hat.com; cheshi@...hat.com;
> mgamal@...hat.com; Eduardo Otubo <otubo@...hat.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@...hat.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ