ixgbe: test for trust in macvlan adjustments for VF
commita9d2d53a788a9c5bc8a7d1b4ea7857b68e221357
authorKen Cox <jkc@redhat.com>
Tue, 15 Nov 2016 19:00:37 +0000 (15 13:00 -0600)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tue, 3 Jan 2017 21:03:36 +0000 (3 13:03 -0800)
tree1c374d3cbfc3df46253e1fefc6fe6c630f66dc2d
parent2dad7b2775ea030c898fe4946971edd25af237d1
ixgbe: test for trust in macvlan adjustments for VF

There are two methods for setting mac addresses in a Macvlan, that
differentiate themselves in the function macvlan_set_mac_Address.
If the macvlan mode is passthru, then we use the dev_set_mac_address
method, otherwise we use the dev_uc api via macvlan_sync_addresses.
The latter method (which would stem from using any non-passthru mode,
like bridge, or vepa), calls down into the driver in a path that terminates
in ixgbevf_set_uc_addr_vf, which sends a IXGBE_VF_SET_MACVLAN message,
which causes the pf to spawn the noted error message.  This occurs because
it appears that the guest is trying to delete the mac address of the macvlan
before adding another.

The other path in macvlan_set_mac_address uses dev_set_mac_address, which
calls into ixgbevf_set_mac which uses the IXGBE_VF_SET_MAC_ADDR to the
pf to set the macvlan mac address.

The discrepancy here is in the handlers.  The handler function for
IXGBE_VF_SET_MAC_ADDR (ixgbe_set_vf_mac_addr) has a check for
the vfinfo[].trusted bit to allow the operation if the vf is trusted.
In comparison, the IXGBE_VF_SET_MACVLAN message handler
(ixgbe_set_vf_macvlan_msg) has no such check of the trusted bit.

Signed-off-by: Ken Cox <jkc@redhat.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c