Menu
▾
▴
Re: [E1000-devel] Possible bug in the i40evf driver
|
From: Fujinaka, T. <tod...@in...> - 2017-08-03 00:15:51
|
Our developer thinks the i40evf driver is guarded against the race issue as you mentioned. The main thing is in i40evf driver, the check/set "while (test_and_set_bit(__I40EVF_IN_CRITICAL_TASK, &adapter->crit_section))" is present ahead of the call of i40evf_napi_disable_all(adapter) in i40evf_reset and i40evf_down. So basically the race condition won't happen as the __I40EVF_IN_CRITICAL_TASK bit check/set prevents it from happening. In the developer's reproduction, the commands were run quickly/repeatedly one after another as shown below. We did see "i40evf 0000:04:0a.1: Failed to get lock in i40evf_set_rx_mode" in dmesg log from time to time and that was there exactly because of the check/set against __I40EVF_IN_CRITICAL_TASK bit. No hang of the driver ever happened. ifconfig eth1 mtu 1000 & ifconfig eth1 up ifconfig eth1 down ethtool -G eth1 rx 4096 Can you give us more information? We need exact reproduction steps, OS/kernel versions, driver & firmware versions (ethtool -i <devname> will show this), and your hardware. You can file a bug on e1000.sourceforge.net to provide the information as attachments, or preferably open an IPS. I know there are IXIA accounts on IPS as I was just sent an issue. Thanks. Todd Fujinaka Software Application Engineer Datacenter Engineering Group Intel Corporation tod...@in... (503) 712-4565 -----Original Message----- From: Fujinaka, Todd [mailto:tod...@in...] Sent: Tuesday, August 1, 2017 1:41 PM To: Codrut Grosu <co...@ix...>; e10...@li... Subject: Re: [E1000-devel] Possible bug in the i40evf driver Thanks! We're having the developers look into this issue. Todd Fujinaka Software Application Engineer Datacenter Engineering Group Intel Corporation tod...@in... (503) 712-4565 -----Original Message----- From: Codrut Grosu [mailto:co...@ix...] Sent: Tuesday, August 1, 2017 8:30 AM To: e10...@li... Subject: [E1000-devel] Possible bug in the i40evf driver Hi, We believe there might be a bug in the i40evf driver. We think that there is race issue between i40evf_reset_task and i40evf_down / i40evf_open. The reason is that the functions napi_enable / napi_disable must be called in pairs in order not to loop indefinitely (or crash). Consider the following: ifconfig eth1 mtu 1000 & ifconfig eth1 up What happens now is that the change of mtu schedules a reset. Suppose the reset task starts, and the first call to netif_running (after continue_reset) returns false. Before the thread reaches the second call to netif_running, i40evf_open starts in another thread. Then the second netif_running in reset will return true, and we will have 2 consecutive calls of napi_enable. We could not reproduce this particular situation in practice (probably due to the short timing). However, we did hang the driver using a call to ndo_close() followed quickly by "ethtool -G eth1 rx 4096". In this case netif_running will return true always (as we bypassed the call to dev_close), the reset will be scheduled before the interface finishes going down, and 2 calls to napi_disable will happen. Please let us know your opinion. Best wishes, Tudor, Codrut ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ E1000-devel mailing list E10...@li... https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ E1000-devel mailing list E10...@li... https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired |
