On Wed, Oct 17, 2018 at 04:26:21PM +0200, Greg Kroah-Hartman wrote:
On Wed, Oct 17, 2018 at 02:15:30PM +0000, Haiyang Zhang wrote:
The VF NIC needs to be paired with synthetic NIC on HyperV -- to do that we use MAC address matching before the patch #A. But a non VF NIC can also have the same MAC, which shouldn't be paired with synthetic NIC. So a better method is implemented by #A to use VF serial number for matching.
But, #A has a bug, which causes matching to fail. Patch #B fixed it by extracting the VF serial number correctly from slot info.
My question is, "what bug is patch #A fixing"? Somehow things have been working just fine for people without this, right? Remember, new features should not be backported to stable kernels if at all possible.
The current mechanism works fine most of the time, the problem is that once in a while we'd see collisions between the synthetic device MAC address and a different network device such as a bond device or just a regular non-VF network device.
So while in most cases assuming that MAC is unique and looking up devices based on it works, there's no guarantee that it's unique so this assumption isn't true and things break.
This is why it (usually) works now, but still has a bug that needs fixing.
If that makes sense, I'll requeue it when the fixes have soaked upstream for a few weeks.
-- Thanks, Sasha