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
