On 3/3/2017 3:17 AM, Qi Zhang wrote: > The VF uses a multi-bit update request to clear unused VLANs whenever it > resets. However, an accident in a previous refector broke multi-bit
s/refector/refactor > updates for VFs, due to misreading a comment in fm10k_vf.c and > attempting to reduce code duplication. The problem occurs because > a multi-bit request has a non-zero length, and the PF would simply drop > any request with the upper 16 bits set. In addition, a multi-bit vlan > update does not have a concept for "VLAN 0" as the single bit update > does. > > A previous revision of this patch resolved the issue by simply removing > the upper 16 bit check and the iov_select_vid checks. However, this would > remove the checks for default VID and for ensuring no other VLANs can be > enabled except pf_vid when it has been set. To resolve that issue, this > revision uses the iov_select_vid when we have a single-bit update, and > denies any multi-bit update when the VLAN was administratively set by > the PF. This should be ok since the PF properly updates VLAN_TABLE when > it assigns the PF vid. This ensures that requests to add or "remove" the > PF vid work as expected, but a rogue VF could not use the multi-bit > update as a loophole to attempt receiving traffic on other VLANs. > > Signed-off-by: Qi Zhang <qi.z.zh...@intel.com> <...>
