netdev - Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link

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: <568DC8A8.5050008@gmail.com>
Date:	Thu, 7 Jan 2016 10:08:40 +0800
From:	zhuyj <zyjzyj2000@...il.com>
To:	"Tantilov, Emil S" <emil.s.tantilov@...el.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

On 01/06/2016 11:30 PM, Tantilov, Emil S wrote:
>> -----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 it is not a valid scenario, maybe there is something wrong with NIC 
driver/hardware.
We should pay attention to it.

Zhu Yanjun

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