From patchwork Tue Apr 16 15:51:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ferruh Yigit X-Patchwork-Id: 52832 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 19EE71B508; Tue, 16 Apr 2019 17:51:41 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id D95D61B507 for ; Tue, 16 Apr 2019 17:51:39 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2019 08:51:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,358,1549958400"; d="scan'208";a="224037203" Received: from silpixa00399752.ir.intel.com (HELO silpixa00399752.ger.corp.intel.com) ([10.237.222.212]) by orsmga001.jf.intel.com with ESMTP; 16 Apr 2019 08:51:28 -0700 From: Ferruh Yigit To: Olivier Matz Cc: dev@dpdk.org, Stephen Hemminger , Chas Williams Date: Tue, 16 Apr 2019 16:51:26 +0100 Message-Id: <20190416155126.26438-1-ferruh.yigit@intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [dpdk-dev] [PATCH] net: do not insert VLAN tag to shared mbufs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" The vlan_insert() is buggy when it tires to handle the shared mbufs, instead don't support inserting VLAN tag into shared mbufs and return an error for that case. Signed-off-by: Ferruh Yigit Acked-by: Olivier Matz --- Cc: Stephen Hemminger Cc: Chas Williams This is another approach to RFC to fix the vlan_insert: https://patches.dpdk.org/patch/51870/ vlan_insert() mostly used by drivers to insert VLAN tag into packet data in Tx path, drivers creating new copies of mbufs in Tx path may result unexpected behavior, like not freed or double freed mbufs. --- lib/librte_net/rte_ether.h | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h index 3a87ff184..a1df911b6 100644 --- a/lib/librte_net/rte_ether.h +++ b/lib/librte_net/rte_ether.h @@ -388,15 +388,8 @@ static inline int rte_vlan_insert(struct rte_mbuf **m) struct vlan_hdr *vh; /* Can't insert header if mbuf is shared */ - if (rte_mbuf_refcnt_read(*m) > 1) { - struct rte_mbuf *copy; - - copy = rte_pktmbuf_clone(*m, (*m)->pool); - if (unlikely(copy == NULL)) - return -ENOMEM; - rte_pktmbuf_free(*m); - *m = copy; - } + if (!RTE_MBUF_DIRECT(*m) || rte_mbuf_refcnt_read(*m) > 1) + return -EINVAL; oh = rte_pktmbuf_mtod(*m, struct ether_hdr *); nh = (struct ether_hdr *)