netdev - Re: [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex

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]

Message-ID: <1450868046.3316.11.camel@intel.com>
Date:	Wed, 23 Dec 2015 02:54:06 -0800
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	zyjzyj2000@...il.com, jesse.brandeburg@...el.com,
	shannon.nelson@...el.com, carolyn.wyborny@...el.com,
	donald.c.skidmore@...el.com, bruce.w.allan@...el.com,
	john.ronciak@...el.com, mitch.a.williams@...el.com,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net
Cc:	venkat.viswanathan@...driver.com, Boris.Shteinbock@...driver.com,
	Vincent.Bourg@...driver.com
Subject: Re: [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and
 getting speed and duplex

On Wed, 2015-12-23 at 14:46 +0800, zyjzyj2000@...il.com wrote:
> From: Zhu Yanjun <zyjzyj2000@...il.com>
> 
> In X540 NIC, there is a time span between reporting "link on" and
> getting the speed and duplex. To a bonding driver in 802.3ad mode,
> this time span will make it not work well if the time span is big
> enough. The big time span will make bonding driver change the state
> of
> the slave device to up while the speed and duplex of the slave device
> can not be gotten. Later the bonding driver will not have change to
> get the speed and duplex of the slave device. The speed and duplex of
> the slave device are important to a bonding driver in 802.3ad mode.
> 
> To 82599_SFP NIC and other kinds of NICs, this problem does
> not exist. As such, it is necessary for X540 to report"link on" when
> the link speed is not IXGBE_LINK_SPEED_UNKNOWN.
> 
> Signed-off-by: Zhu Yanjun <zyjzyj2000@...il.com>
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   16
> +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index aed8d02..cb9d310 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6479,7 +6479,21 @@ static void ixgbe_watchdog_link_is_up(struct
> ixgbe_adapter *adapter)
>  	       (flow_rx ? "RX" :
>  	       (flow_tx ? "TX" : "None"))));
>  
> -	netif_carrier_on(netdev);
> +	/*
> +	 * In X540 NIC, there is a time span between reporting "link
> on"
> +	 * and getting the speed and duplex. To a bonding driver in
> 802.3ad
> +	 * mode, this time span will make it not work well if the
> time span
> +	 * is big enough. To 82599_SFP NIC and other kinds of NICs,
> this
> +	 * problem does not exist. As such, it is better for X540 to
> report
> +	 * "link on" when the link speed is not
> IXGBE_LINK_SPEED_UNKNOWN.
> +	 */
> +	if ((hw->mac.type == ixgbe_mac_X540) &&
> +	    (link_speed != IXGBE_LINK_SPEED_UNKNOWN)) {
> +		netif_carrier_on(netdev);
> +	} else {
> +		netif_carrier_on(netdev);
> +	}
> +
>  	ixgbe_check_vf_rate_limit(adapter);
>  
>  	/* enable transmits */

This patch only adds a needless test before
calling netif_carrier_on(netdev), since the call happens no matter the
branch you take, it appears your running into a timing issue.  So
adding a wait() before calling netif_carrier_on(netdev) will accomplish
the same result and you do not have to add a useless test.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)