From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AIpwx49rW59lhtk0QBC5L7nZWgaHsVjHCRXNKLaJHaCP5QaRmO+B28VUNlH00L1/Fc1CnJybXQzk ARC-Seal: i=1; a=rsa-sha256; t=1524652834; cv=none; d=google.com; s=arc-20160816; b=gCFUSCzEVJ2ERA01Ms17yBZefVO3qvWnFDmJ2SuPSDUfUL0FV07X6rcM13mFWasyI7 u1F5m3irPPspkBRMWyWyXVmxY3qbtavE8lj3Xsdx6JhUUe0jZr9g30unydVVy3lACoTA LL0yUpE2zlO1ZpdpPZXNxtn0bsE26b3SXc8M9mEcjvtBcfsTWa6A9Dp600inAPO/Zykq HBhC6CILHXew0njFzg0Q2MTIl9azfGumI3Bw71YbXyu4PSlZ7R/JVIaHofDfbfVygOYC yerOV3mDzXWyo0VRMc4MxXB5fUsZt4EZt9CIKg0Bj+iwYDFX5RI5HlJYAyUUf4b1zx8A ZK9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=APgKXjM/YXa4KGzXSxs6e2khlh00wEWTx6vfdP2MOgM=; b=AGbnT0WCVMwacjuNQV573TYEzVPQGrD97OPTupM1pefHRKHiX1q8dNjznHcXpUlX2t ZJLQXVXF41vXGpr3O2wOkYgzPX+9na3NRiW3uXjiLhbEyYb/xZOnD+T0BEy0fPA4TqfD PzVBpa5u9PHRgvDQDrMhECCVHQcQsl7uqPpVkC8nGJYE7YadsMXyGk+djEyd/y8W9Z6y pDFjvhm6QQkExHOI2Ofunkkw/hBOz9QtGeqfB4nUQu2xVPfbeMdaPO+4ewYIhWObCEWe dMn8VpcgPhmNb9CAx4GqE19gu2HsfMJOnq9PHXNEaBRTMnGaFocPxWV98a13t/DgI5X7 Vpnw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning gregkh@linuxfoundation.org does not designate 90.92.61.202 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning gregkh@linuxfoundation.org does not designate 90.92.61.202 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ngai-Mint Kwan , Jacob Keller , Krishneil Singh , Jeff Kirsher , Sasha Levin Subject: [PATCH 4.14 086/183] fm10k: fix "failed to kill vid" message for VF Date: Wed, 25 Apr 2018 12:35:06 +0200 Message-Id: <20180425103245.955091246@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180425103242.532713678@linuxfoundation.org> References: <20180425103242.532713678@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcU2VudCI=?= X-GMAIL-THRID: =?utf-8?q?1598714371435092622?= X-GMAIL-MSGID: =?utf-8?q?1598714371435092622?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ngai-Mint Kwan [ Upstream commit cf315ea596ec26d7aa542a9ce354990875a920c0 ] When a VF is under PF VLAN assignment: ip link set vf <#> vlan This will remove all previous entries in the VLAN table including those generated by VLAN interfaces created on the VF. The issue arises when the VF is under PF VLAN assignment and one or more of these VLAN interfaces of the VF are deleted. When deleting these VLAN interfaces, the following message will be generated in "dmesg": failed to kill vid 0081/ for device This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error. The handler for this ndo is "fm10k_update_vid". Any calls to this function while under PF VLAN management will exit prematurely and, thus, it will generate the failure message. Additionally, since "fm10k_update_vid" exits prematurely, none of the VLAN update is performed. So, even though the actual VLAN interfaces of the VF will be deleted, the active_vlans bitmask is not cleared. When the VF is no longer under PF VLAN assignment, the driver mistakenly restores the previous entries of the VLAN table based on an unsynchronized list of active VLANs. The solution to this issue involves checking the VLAN update action type before exiting "fm10k_update_vid". If the VLAN update action type is to "add", this action will not be permitted while the VF is under PF VLAN assignment and the VLAN update is abandoned like before. However, if the VLAN update action type is to "kill", then we need to also clear the active_vlans bitmask. However, we don't need to actually queue any messages to the PF, because the MAC and VLAN tables have already been cleared, and the PF would silently ignore these requests anyways. Signed-off-by: Ngai-Mint Kwan Signed-off-by: Jacob Keller Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c @@ -815,8 +815,12 @@ static int fm10k_update_vid(struct net_d if (vid >= VLAN_N_VID) return -EINVAL; - /* Verify we have permission to add VLANs */ - if (hw->mac.vlan_override) + /* Verify that we have permission to add VLANs. If this is a request + * to remove a VLAN, we still want to allow the user to remove the + * VLAN device. In that case, we need to clear the bit in the + * active_vlans bitmask. + */ + if (set && hw->mac.vlan_override) return -EACCES; /* update active_vlans bitmask */ @@ -835,6 +839,12 @@ static int fm10k_update_vid(struct net_d rx_ring->vid &= ~FM10K_VLAN_CLEAR; } + /* If our VLAN has been overridden, there is no reason to send VLAN + * removal requests as they will be silently ignored. + */ + if (hw->mac.vlan_override) + return 0; + /* Do not remove default VLAN ID related entries from VLAN and MAC * tables */