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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 22 Sep 2013 10:56:35 +0800
From:	annie li <annie.li@...cle.com>
To:	Paul Durrant <paul.durrant@...rix.com>
CC:	netdev@...r.kernel.org, xen-devel@...ts.xen.org,
	Wei Liu <wei.liu2@...rix.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Ian Campbell <ian.campbell@...rix.com>
Subject: Re: [Xen-devel] [PATCH net-next v2 1/2] xen-netback: add a vif-is-connected
 flag


On 2013-9-20 21:57, Paul Durrant wrote:
> Having applied my patch to separate vif disconnect and free, I ran into a
> BUG when testing resume from S3 with a Windows frontend because the vif task
> pointer was not cleared by xenvif_disconnect() and so a double call to this
> function tries to stop the thread twice.
Or it is better to do more implements in windows netfront? For example, 
when the windows vm hibernates, disconnect the vif as required by 
netback: connect-> closing-> closed.

Thanks
Annie

> Rather than applying a point fix for that issue it seems better to introduce
> a boolean to indicate whether the vif is connected or not such that repeated
> calls to either xenvif_connect() or xenvif_disconnect() behave appropriately.
>
> Signed-off-by: Paul Durrant <paul.durrant@...rix.com>
> Cc: David Vrabel <david.vrabel@...rix.com>
> Cc: Wei Liu <wei.liu2@...rix.com>
> Cc: Ian Campbell <ian.campbell@...rix.com>
> ---
>   drivers/net/xen-netback/common.h    |    1 +
>   drivers/net/xen-netback/interface.c |   24 +++++++++++++-----------
>   2 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 5715318..860d92c 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -169,6 +169,7 @@ struct xenvif {
>   
>   	/* Miscellaneous private stuff. */
>   	struct net_device *dev;
> +	bool connected;
>   };
>   
>   static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 01bb854..94b47f5 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -366,7 +366,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>   	int err = -ENOMEM;
>   
>   	/* Already connected through? */
> -	if (vif->tx_irq)
> +	if (vif->connected)
>   		return 0;
>   
>   	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
> @@ -425,6 +425,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>   
>   	wake_up_process(vif->task);
>   
> +	vif->connected = 1;
>   	return 0;
>   
>   err_rx_unbind:
> @@ -453,23 +454,24 @@ void xenvif_carrier_off(struct xenvif *vif)
>   
>   void xenvif_disconnect(struct xenvif *vif)
>   {
> +	if (!vif->connected)
> +		return;
> +
>   	if (netif_carrier_ok(vif->dev))
>   		xenvif_carrier_off(vif);
>   
> -	if (vif->tx_irq) {
> -		if (vif->tx_irq == vif->rx_irq)
> -			unbind_from_irqhandler(vif->tx_irq, vif);
> -		else {
> -			unbind_from_irqhandler(vif->tx_irq, vif);
> -			unbind_from_irqhandler(vif->rx_irq, vif);
> -		}
> -		vif->tx_irq = 0;
> +	if (vif->tx_irq == vif->rx_irq)
> +		unbind_from_irqhandler(vif->tx_irq, vif);
> +	else {
> +		unbind_from_irqhandler(vif->tx_irq, vif);
> +		unbind_from_irqhandler(vif->rx_irq, vif);
>   	}
>   
> -	if (vif->task)
> -		kthread_stop(vif->task);
> +	kthread_stop(vif->task);
>   
>   	xenvif_unmap_frontend_rings(vif);
> +
> +	vif->connected = 0;
>   }
>   
>   void xenvif_free(struct xenvif *vif)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ