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: <87618083B2453E4A8714035B62D6799250503F00@FMSMSX105.amr.corp.intel.com>
Date:	Wed, 6 Jan 2016 15:30:36 +0000
From:	"Tantilov, Emil S" <emil.s.tantilov@...el.com>
To:	zhuyj <zyjzyj2000@...il.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Nelson, Shannon" <shannon.nelson@...el.com>,
	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Williams, Mitch A" <mitch.a.williams@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
CC:	"Viswanathan, Ven (Wind River)" <venkat.viswanathan@...driver.com>,
	"Shteinbock, Boris (Wind River)" <boris.shteinbock@...driver.com>,
	"Bourg, Vincent (Wind River)" <vincent.bourg@...driver.com>
Subject: RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
 of link_up and speed

>-----Original Message-----
>From: zhuyj [mailto:zyjzyj2000@...il.com]
>Sent: Tuesday, January 05, 2016 9:42 PM
>To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>John; Williams, Mitch A; intel-wired-lan@...ts.osuosl.org;
>netdev@...r.kernel.org; e1000-devel@...ts.sourceforge.net
>Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
>Vincent (Wind River)
>Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
>of link_up and speed
>
>On 12/31/2015 12:37 AM, Tantilov, Emil S wrote:
>>> -----Original Message-----
>>> From: zhuyj [mailto:zyjzyj2000@...il.com]
>>> Sent: Wednesday, December 30, 2015 12:20 AM
>>> To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>>> Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>>> John; Williams, Mitch A; intel-wired-lan@...ts.osuosl.org;
>>> netdev@...r.kernel.org; e1000-devel@...ts.sourceforge.net
>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>Bourg,
>>> Vincent (Wind River)
>>> Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict
>synchronization
>>> of link_up and speed
>>>
>>> On 12/30/2015 02:55 PM, Tantilov, Emil S wrote:
>>>>> -----Original Message-----
>>>>> From: zhuyj [mailto:zyjzyj2000@...il.com]
>>>>> Sent: Tuesday, December 29, 2015 6:49 PM
>>>>> To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>>>>> Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W;
>Ronciak,
>>>>> John; Williams, Mitch A; intel-wired-lan@...ts.osuosl.org;
>>>>> netdev@...r.kernel.org; e1000-devel@...ts.sourceforge.net
>>>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>>> Bourg,
>>>>> Vincent (Wind River)
>>>>> Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict
>>> synchronization
>>>>> of link_up and speed
>>>>>
>>>>> On 12/30/2015 12:18 AM, Tantilov, Emil S wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Intel-wired-lan [mailto:intel-wired-lan-
>>> bounces@...ts.osuosl.org]
>>>>> On
>>>>>>> Behalf Of zyjzyj2000@...il.com
>>>>>>> Sent: Monday, December 28, 2015 6:32 PM
>>>>>>> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
>>>>>>> Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John;
>Williams,
>>>>> Mitch
>>>>>>> A; intel-wired-lan@...ts.osuosl.org; netdev@...r.kernel.org; e1000-
>>>>>>> devel@...ts.sourceforge.net
>>>>>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>>>>> Bourg,
>>>>>>> Vincent (Wind River)
>>>>>>> Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict
>synchronization
>>>>> of
>>>>>>> link_up and speed
>>>>>>>
>>>>>>> From: Zhu Yanjun <yanjun.zhu@...driver.com>
>>>>>>>
>>>>>>> When the X540 NIC acts as a slave of some virtual NICs, it is very
>>>>>>> important to synchronize link_up and link_speed, such as a bonding
>>>>>>> driver in 802.3ad mode. When X540 NIC acts as an independent
>>> interface,
>>>>>>> it is not necessary to synchronize link_up and link_speed. That is,
>>>>>>> the time span between link_up and link_speed is acceptable.
>>>>>> What exactly do you mean by "time span between link_up and
>link_speed"?
>>>>> In the previous mail, I show you some ethtool logs. In these logs,
>there
>>>>> is some
>>>>> time with NIC up while speed is unknown. I think this "some time" is
>>>>> time span between
>>>>> link_up and link_speed. Please see the previous mail for details.
>>>> Was this when reporting the link state from check_link() (reading the
>>> LINKS
>>>> register) or reporting the adapter->link_speed?
>>>>
>>>>>> Where is it you think the de-synchronization occurs?
>>>>> When a NIC interface acts as a slave, a flag "IFF_SLAVE" is set in
>>>>> netdevice struct.
>>>>> Before we enter this function, we check IFF_SLAVE flag. If this flag
>is
>>>>> set, we continue to check
>>>>> link_speed. If not, this function is executed whether this link_speed
>is
>>>>> unknown or not.
>>>> I can already see this in your patch. I was asking about the reason why
>>>> your change is needed.
>>> an extreme example, let us assume this scenario:
>> Is this the scenario you are trying to fix?
>Sure. If IFF_SLAVE is checked, this scenario will not happen.

I already explained why this is not a valid scenario, but if you were able
to set it up somehow I'd like to know how you did it

If we are to enter ixgbe_watchdog_link_is_up() with unknown link this would
be an issue regardless of whether the interface is a part of a bond or not, 
but you haven't provided any proof that this is the case. Do you have a
dmesg log that shows ixgbe reporting unknown speed?

Was your patch tested by the customer that reported this issue?

Thanks,
Emil

--
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