[dpdk-stable] [PATCH 14/17] net/qede/base: fix access to an uninitialized list

[dpdk-stable] [PATCH 14/17] net/qede/base: fix access to an uninitialized list

[Rasesh Mody]

Fix an access to an uninitialized list when the management FW is not
initialized by simply doing the list initialization always, at a previous
step, before ecore_mcp_cmd_init() can stop in the middle and return.

Fixes: c1796ac8da2d ("net/qede/base: revise management FW mbox access scheme")
Cc: stable@dpdk.org

Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com>
---
 drivers/net/qede/base/ecore_mcp.c |   25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/net/qede/base/ecore_mcp.c b/drivers/net/qede/base/ecore_mcp.c
index 85cd271..3802aa8 100644
--- a/drivers/net/qede/base/ecore_mcp.c
+++ b/drivers/net/qede/base/ecore_mcp.c
@@ -156,6 +156,9 @@ enum _ecore_status_t ecore_mcp_free(struct ecore_hwfn *p_hwfn)
 	if (p_hwfn->mcp_info) {
 		struct ecore_mcp_cmd_elem *p_cmd_elem = OSAL_NULL, *p_tmp;
 
+		OSAL_FREE(p_hwfn->p_dev, p_hwfn->mcp_info->mfw_mb_cur);
+		OSAL_FREE(p_hwfn->p_dev, p_hwfn->mcp_info->mfw_mb_shadow);
+
 		OSAL_SPIN_LOCK(&p_hwfn->mcp_info->cmd_lock);
 		OSAL_LIST_FOR_EACH_ENTRY_SAFE(p_cmd_elem, p_tmp,
 					      &p_hwfn->mcp_info->cmd_list, list,
@@ -164,8 +167,6 @@ enum _ecore_status_t ecore_mcp_free(struct ecore_hwfn *p_hwfn)
 		}
 		OSAL_SPIN_UNLOCK(&p_hwfn->mcp_info->cmd_lock);
 
-		OSAL_FREE(p_hwfn->p_dev, p_hwfn->mcp_info->mfw_mb_cur);
-		OSAL_FREE(p_hwfn->p_dev, p_hwfn->mcp_info->mfw_mb_shadow);
 #ifdef CONFIG_ECORE_LOCK_ALLOC
 		OSAL_SPIN_LOCK_DEALLOC(&p_hwfn->mcp_info->cmd_lock);
 		OSAL_SPIN_LOCK_DEALLOC(&p_hwfn->mcp_info->link_lock);
@@ -244,6 +245,16 @@ enum _ecore_status_t ecore_mcp_cmd_init(struct ecore_hwfn *p_hwfn,
 		goto err;
 	p_info = p_hwfn->mcp_info;
 
+	/* Initialize the MFW spinlocks */
+#ifdef CONFIG_ECORE_LOCK_ALLOC
+	OSAL_SPIN_LOCK_ALLOC(p_hwfn, &p_info->cmd_lock);
+	OSAL_SPIN_LOCK_ALLOC(p_hwfn, &p_info->link_lock);
+#endif
+	OSAL_SPIN_LOCK_INIT(&p_info->cmd_lock);
+	OSAL_SPIN_LOCK_INIT(&p_info->link_lock);
+
+	OSAL_LIST_INIT(&p_info->cmd_list);
+
 	if (ecore_load_mcp_offsets(p_hwfn, p_ptt) != ECORE_SUCCESS) {
 		DP_NOTICE(p_hwfn, false, "MCP is not initialized\n");
 		/* Do not free mcp_info here, since public_base indicate that
@@ -258,16 +269,6 @@ enum _ecore_status_t ecore_mcp_cmd_init(struct ecore_hwfn *p_hwfn,
 	if (!p_info->mfw_mb_shadow || !p_info->mfw_mb_addr)
 		goto err;
 
-	/* Initialize the MFW spinlocks */
-#ifdef CONFIG_ECORE_LOCK_ALLOC
-	OSAL_SPIN_LOCK_ALLOC(p_hwfn, &p_info->cmd_lock);
-	OSAL_SPIN_LOCK_ALLOC(p_hwfn, &p_info->link_lock);
-#endif
-	OSAL_SPIN_LOCK_INIT(&p_info->cmd_lock);
-	OSAL_SPIN_LOCK_INIT(&p_info->link_lock);
-
-	OSAL_LIST_INIT(&p_info->cmd_list);
-
 	return ECORE_SUCCESS;
 
 err:
-- 
1.7.10.3

[dpdk-stable] [PATCH 15/17] net/qede/base: fix for VF malicious indication

[Rasesh Mody]

IOV regression testing led to discovery of a minor issue + possibly race in
IOV flows:
 a. Malicious indications in VF-database on PF-side get cleared during FLR
    flows - but not when disabling SRIOV. At least in linux if you disable
    IOV while having a malicious VF you wouldn't be able to clear the
    indication as driver would prevent from initializing it.
 b. Possible race during PF response to VF - the channel is made ready only
    after sending the rc via dmae to VF. It's possible due to context
    switch at end of DMAE [when releasing Mutex] that VF would start
    running and send another message prior to PF clearing the channel,
    making the FW consider that VF to be malicious.

This patch fixes that by
 - clearing the indication even if we're only going ito disable VF
 - resetting the channel to ready before PF copies the rc to the VF, PF can
   then continue and send an additional message

Fixes: 47b302d64624 ("net/qede/base: add handling of malicious VF")
Fixes: 86a2265e59d7 ("qede: add SRIOV support")
Cc: stable@dpdk.org

Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com>
---
 drivers/net/qede/base/ecore_sriov.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/net/qede/base/ecore_sriov.c b/drivers/net/qede/base/ecore_sriov.c
index b85718f..18458cf 100644
--- a/drivers/net/qede/base/ecore_sriov.c
+++ b/drivers/net/qede/base/ecore_sriov.c
@@ -865,6 +865,11 @@ static void ecore_iov_vf_igu_set_int(struct ecore_hwfn *p_hwfn,
 	u32 igu_vf_conf = IGU_VF_CONF_FUNC_EN;
 	enum _ecore_status_t rc = ECORE_SUCCESS;
 
+	/* It's possible VF was previously considered malicious -
+	 * clear the indication even if we're only going to disable VF.
+	 */
+	vf->b_malicious = false;
+
 	if (vf->to_disable)
 		return ECORE_SUCCESS;
 
@@ -877,8 +882,6 @@ static void ecore_iov_vf_igu_set_int(struct ecore_hwfn *p_hwfn,
 
 	ecore_iov_vf_igu_reset(p_hwfn, p_ptt, vf);
 
-	/* It's possible VF was previously considered malicious */
-	vf->b_malicious = false;
 	rc = ecore_iov_enable_vf_access_msix(p_hwfn, p_ptt,
 					     vf->abs_vf_id, vf->num_sbs);
 	if (rc != ECORE_SUCCESS)
@@ -1397,14 +1400,18 @@ static void ecore_iov_send_response(struct ecore_hwfn *p_hwfn,
 			     (sizeof(union pfvf_tlvs) - sizeof(u64)) / 4,
 			     &params);
 
-	ecore_dmae_host2host(p_hwfn, p_ptt, mbx->reply_phys,
-			     mbx->req_virt->first_tlv.reply_address,
-			     sizeof(u64) / 4, &params);
-
+	/* Once PF copies the rc to the VF, the latter can continue and
+	 * and send an additional message. So we have to make sure the
+	 * channel would be re-set to ready prior to that.
+	 */
 	REG_WR(p_hwfn,
 	       GTT_BAR0_MAP_REG_USDM_RAM +
 	       USTORM_VF_PF_CHANNEL_READY_OFFSET(eng_vf_id), 1);
 
+	ecore_dmae_host2host(p_hwfn, p_ptt, mbx->reply_phys,
+			     mbx->req_virt->first_tlv.reply_address,
+			     sizeof(u64) / 4, &params);
+
 	OSAL_IOV_PF_RESP_TYPE(p_hwfn, p_vf->relative_vf_id, status);
 }
 
-- 
1.7.10.3

[dpdk-stable] [PATCH 16/17] net/qede/base: fix return code to align with FW

[Rasesh Mody]

This change aligns the PF behavior with that of the L2-fw, so that flows
(to remove an incorrect MAC) for PF and VF could remain the same.

Fixes: 86a2265e59d7 ("qede: add SRIOV support")
Cc: stable@dpdk.org

Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com>
---
 drivers/net/qede/base/ecore_sriov.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/qede/base/ecore_sriov.c b/drivers/net/qede/base/ecore_sriov.c
index 18458cf..b1e26d6 100644
--- a/drivers/net/qede/base/ecore_sriov.c
+++ b/drivers/net/qede/base/ecore_sriov.c
@@ -3419,12 +3419,13 @@ static void ecore_iov_vf_mbx_ucast_filter(struct ecore_hwfn *p_hwfn,
 		goto out;
 	}
 
-	/* Update shadow copy of the VF configuration */
+	/* Update shadow copy of the VF configuration. In case shadow indicates
+	 * the action should be blocked return success to VF to imitate the
+	 * firmware behaviour in such case.
+	 */
 	if (ecore_iov_vf_update_unicast_shadow(p_hwfn, vf, &params) !=
-	    ECORE_SUCCESS) {
-		status = PFVF_STATUS_FAILURE;
+	    ECORE_SUCCESS)
 		goto out;
-	}
 
 	/* Determine if the unicast filtering is acceptible by PF */
 	if ((p_bulletin->valid_bitmap & (1 << VLAN_ADDR_FORCED)) &&
-- 
1.7.10.3