From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 58AF2A034C for ; Fri, 30 Sep 2022 09:24:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BA21842BD9; Fri, 30 Sep 2022 09:24:28 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 2E1E542BCB; Fri, 30 Sep 2022 09:24:23 +0200 (CEST) Received: from kwepemi500017.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Mf1ql4JgRzpSxj; Fri, 30 Sep 2022 15:21:23 +0800 (CST) Received: from localhost.localdomain (10.28.79.22) by kwepemi500017.china.huawei.com (7.221.188.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 30 Sep 2022 15:24:21 +0800 From: Dongdong Liu To: , , , CC: , , , , , Subject: [PATCH 18/19] net/hns3: fix VF mark wrong message processed Date: Fri, 30 Sep 2022 15:22:19 +0800 Message-ID: <20220930072220.20753-19-liudongdong3@huawei.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20220930072220.20753-1-liudongdong3@huawei.com> References: <20220930072220.20753-1-liudongdong3@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.28.79.22] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemi500017.china.huawei.com (7.221.188.110) X-CFilter-Loop: Reflected X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org From: Chengwen Feng VF's command receive queue was mainly used to receive mailbox messages from PF. There are two type mailbox messages: request response message and message pushed by PF. There are two types of threads that can handle these messages: 1) the interrupt thread of the main process: it could handle both types of messages. 2) other threads: it could only handle request response messages. The collaboration mechanism between the two type threads is that other threads set the opcode of processed messages to zero so that the interrupt thread of the main process does not process these messages again. Unfortunately, the other threads mark the message pointed to by the crq->next-to-use variable which is fixed in the loop, not the message pointed to by the next-to-use variable. This patch fixes it. Fixes: dbbbad23e380 ("net/hns3: fix VF handling LSC event in secondary process") Cc: stable@dpdk.org Signed-off-by: Chengwen Feng Signed-off-by: Dongdong Liu --- drivers/net/hns3/hns3_mbx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c index 910a16c999..8e0a58aa02 100644 --- a/drivers/net/hns3/hns3_mbx.c +++ b/drivers/net/hns3/hns3_mbx.c @@ -429,7 +429,7 @@ hns3_handle_mbx_msg_out_intr(struct hns3_hw *hw) * Clear opcode to inform intr thread don't process * again. */ - crq->desc[crq->next_to_use].opcode = 0; + crq->desc[next_to_use].opcode = 0; } scan_next: -- 2.22.0