From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 88C9E56A1 for ; Wed, 27 Mar 2019 16:18:43 +0100 (CET) Received: by mail-pl1-f194.google.com with SMTP id k2so3465584plt.3 for ; Wed, 27 Mar 2019 08:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=T2kkvrLYh/upLVOfwh/hh8yNnDt4LUos/w/rJd9S9no=; b=UiMYZ8zsKgN2LVRzoyaVoqTCAQ/Yx30oCLEe3aYRksfhQc4IqCdJi/oT88eGMcv6lD t8suyaiH2tHiXMX1ev8XW1z6s7r/PXVwnZrhWmfKwupqzMZRRFjWhY1edu+WwrEKODSJ LlgKyp3tSkt5GHUsG9PuYtPfEQz3pJgOLGaY8iTBVVFZTVjeZbixlnVeVXW08xwINFip AVYHYyrCBzx0dTezgt/JjFeGSgDctycCoqWiZNSosG4oDVW6W65gT2nbbv/NyM1C2f7H 5n42ZTVQrCQGEUObFxLg2l+Yjcl5Mtetx/XliN6gfypozXBY+Noq5Z8nyKNRcip+6hN+ fnvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=T2kkvrLYh/upLVOfwh/hh8yNnDt4LUos/w/rJd9S9no=; b=pfs1cUrFgK3rqh2jD719MXDxq8/LFVX6ItiLmD1VUACUfCsKanlTXiiaui6CEFKrYi RPpWgaPcGq4HLmukzHPivHzWgVjhXWC3lQMo8s3A+84sSxMago+VcfYuv1GHMgmWWkAp n4WJYvf8t1O9Qd8z+CgaXM5gj8KqO5FYT4iNo0wwW7PZBk8pAuZCQBzzp74dAdx11yn9 W9d5561lLmU+U/GyhIgDak1kpvx39iitNw6YTKrB4QEK7B2NKfY6QJiER1pOjyP5M1m8 JgHfqUIT5O0x295SDCup8MHusS1hNkKU4QVAvpRiwRB2s70CKeBa3FFRkCpFd0A0UQBa SKHQ== X-Gm-Message-State: APjAAAVt2KPCEpp7w+hFOLL6ccSxZAqx7YUFGp1HVgk+8agq5KPodAFS UQWo78zTUNb9H2rLDefYcMEGYQ== X-Google-Smtp-Source: APXvYqySKox1qIlkcxbAGrZ1P4RQ//ejM+Ydzr5GmWiqlVWuktJiXUGQEAOOarkaQMkUVggFKjJOLA== X-Received: by 2002:a17:902:f084:: with SMTP id go4mr38005981plb.15.1553699922195; Wed, 27 Mar 2019 08:18:42 -0700 (PDT) Received: from shemminger-XPS-13-9360 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id k10sm33431333pgj.11.2019.03.27.08.18.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Mar 2019 08:18:42 -0700 (PDT) Date: Wed, 27 Mar 2019 08:18:38 -0700 From: Stephen Hemminger To: Chas Williams <3chas3@gmail.com> Cc: dev@dpdk.org, Stephen Hemminger Message-ID: <20190327081838.46c46907@shemminger-XPS-13-9360> In-Reply-To: <0889dffe-e9d8-f480-0480-5b9950fcbbf9@gmail.com> References: <20190326191516.20675-1-stephen@networkplumber.org> <0889dffe-e9d8-f480-0480-5b9950fcbbf9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net: fix rte_vlan_insert with shared mbuf 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: , X-List-Received-Date: Wed, 27 Mar 2019 15:18:44 -0000 On Tue, 26 Mar 2019 18:38:57 -0400 Chas Williams <3chas3@gmail.com> wrote: > On 3/26/19 3:15 PM, Stephen Hemminger wrote: > > If mbuf refcnt was > 1 then rte_vlan_insert() would incorrectly > > modify the original copy. Original code was expecting clone to make > > a copy (it doesn't). Better to let the caller deal with making > > a copy or setting up mbuf chain to allow for header to be added. > > > > Also fix docbook comment about parameters (function takes > > pointer to mbuf). > > > > Fixes: c974021a5949 ("ether: add soft vlan encap/decap") > > Signed-off-by: Stephen Hemminger > > --- > > lib/librte_net/rte_ether.h | 15 ++++----------- > > 1 file changed, 4 insertions(+), 11 deletions(-) > > > > diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h > > index c2c5e249ffe9..bab2b198fa79 100644 > > --- a/lib/librte_net/rte_ether.h > > +++ b/lib/librte_net/rte_ether.h > > @@ -374,7 +374,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m) > > * Software version of VLAN unstripping > > * > > * @param m > > - * The packet mbuf. > > + * Pointer to the packet mbuf. > > * @return > > * - 0: On success > > * -EPERM: mbuf is is shared overwriting would be unsafe > > @@ -385,16 +385,9 @@ static inline int rte_vlan_insert(struct rte_mbuf **m) > > struct ether_hdr *oh, *nh; > > 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; > > - } > > + /* Can't directly insert header if mbuf is shared */ > > + if (rte_mbuf_refcnt_read(*m) > 1) > > This check probably isn't sufficient. You need something more like: > > if (rte_mbuf_refcnt_read(mbuf) > 1 || > (RTE_MBUF_INDIRECT(mbuf) && > rte_mbuf_refcnt_read(rte_mbuf_from_indirect(mbuf)) > 1)) { > > If this is a cloned packet, the refcnt will be 1. So you need to examine > the parent mbuf to see if other clones exist. > The problem is that indirect buffers probably can't be overwritten because of lack of headroom. Actually, why not push the problem into the pktmbuf_headroom logic? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D8585A05D3 for ; Wed, 27 Mar 2019 16:18:45 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D5C2D5B2C; Wed, 27 Mar 2019 16:18:44 +0100 (CET) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 88C9E56A1 for ; Wed, 27 Mar 2019 16:18:43 +0100 (CET) Received: by mail-pl1-f194.google.com with SMTP id k2so3465584plt.3 for ; Wed, 27 Mar 2019 08:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=T2kkvrLYh/upLVOfwh/hh8yNnDt4LUos/w/rJd9S9no=; b=UiMYZ8zsKgN2LVRzoyaVoqTCAQ/Yx30oCLEe3aYRksfhQc4IqCdJi/oT88eGMcv6lD t8suyaiH2tHiXMX1ev8XW1z6s7r/PXVwnZrhWmfKwupqzMZRRFjWhY1edu+WwrEKODSJ LlgKyp3tSkt5GHUsG9PuYtPfEQz3pJgOLGaY8iTBVVFZTVjeZbixlnVeVXW08xwINFip AVYHYyrCBzx0dTezgt/JjFeGSgDctycCoqWiZNSosG4oDVW6W65gT2nbbv/NyM1C2f7H 5n42ZTVQrCQGEUObFxLg2l+Yjcl5Mtetx/XliN6gfypozXBY+Noq5Z8nyKNRcip+6hN+ fnvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=T2kkvrLYh/upLVOfwh/hh8yNnDt4LUos/w/rJd9S9no=; b=pfs1cUrFgK3rqh2jD719MXDxq8/LFVX6ItiLmD1VUACUfCsKanlTXiiaui6CEFKrYi RPpWgaPcGq4HLmukzHPivHzWgVjhXWC3lQMo8s3A+84sSxMago+VcfYuv1GHMgmWWkAp n4WJYvf8t1O9Qd8z+CgaXM5gj8KqO5FYT4iNo0wwW7PZBk8pAuZCQBzzp74dAdx11yn9 W9d5561lLmU+U/GyhIgDak1kpvx39iitNw6YTKrB4QEK7B2NKfY6QJiER1pOjyP5M1m8 JgHfqUIT5O0x295SDCup8MHusS1hNkKU4QVAvpRiwRB2s70CKeBa3FFRkCpFd0A0UQBa SKHQ== X-Gm-Message-State: APjAAAVt2KPCEpp7w+hFOLL6ccSxZAqx7YUFGp1HVgk+8agq5KPodAFS UQWo78zTUNb9H2rLDefYcMEGYQ== X-Google-Smtp-Source: APXvYqySKox1qIlkcxbAGrZ1P4RQ//ejM+Ydzr5GmWiqlVWuktJiXUGQEAOOarkaQMkUVggFKjJOLA== X-Received: by 2002:a17:902:f084:: with SMTP id go4mr38005981plb.15.1553699922195; Wed, 27 Mar 2019 08:18:42 -0700 (PDT) Received: from shemminger-XPS-13-9360 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id k10sm33431333pgj.11.2019.03.27.08.18.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Mar 2019 08:18:42 -0700 (PDT) Date: Wed, 27 Mar 2019 08:18:38 -0700 From: Stephen Hemminger To: Chas Williams <3chas3@gmail.com> Cc: dev@dpdk.org, Stephen Hemminger Message-ID: <20190327081838.46c46907@shemminger-XPS-13-9360> In-Reply-To: <0889dffe-e9d8-f480-0480-5b9950fcbbf9@gmail.com> References: <20190326191516.20675-1-stephen@networkplumber.org> <0889dffe-e9d8-f480-0480-5b9950fcbbf9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net: fix rte_vlan_insert with shared mbuf 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" Message-ID: <20190327151838.FWsxM1kDyW6PXA-hx0xWaeOBJolVAX92oFTDFN3eL74@z> On Tue, 26 Mar 2019 18:38:57 -0400 Chas Williams <3chas3@gmail.com> wrote: > On 3/26/19 3:15 PM, Stephen Hemminger wrote: > > If mbuf refcnt was > 1 then rte_vlan_insert() would incorrectly > > modify the original copy. Original code was expecting clone to make > > a copy (it doesn't). Better to let the caller deal with making > > a copy or setting up mbuf chain to allow for header to be added. > > > > Also fix docbook comment about parameters (function takes > > pointer to mbuf). > > > > Fixes: c974021a5949 ("ether: add soft vlan encap/decap") > > Signed-off-by: Stephen Hemminger > > --- > > lib/librte_net/rte_ether.h | 15 ++++----------- > > 1 file changed, 4 insertions(+), 11 deletions(-) > > > > diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h > > index c2c5e249ffe9..bab2b198fa79 100644 > > --- a/lib/librte_net/rte_ether.h > > +++ b/lib/librte_net/rte_ether.h > > @@ -374,7 +374,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m) > > * Software version of VLAN unstripping > > * > > * @param m > > - * The packet mbuf. > > + * Pointer to the packet mbuf. > > * @return > > * - 0: On success > > * -EPERM: mbuf is is shared overwriting would be unsafe > > @@ -385,16 +385,9 @@ static inline int rte_vlan_insert(struct rte_mbuf **m) > > struct ether_hdr *oh, *nh; > > 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; > > - } > > + /* Can't directly insert header if mbuf is shared */ > > + if (rte_mbuf_refcnt_read(*m) > 1) > > This check probably isn't sufficient. You need something more like: > > if (rte_mbuf_refcnt_read(mbuf) > 1 || > (RTE_MBUF_INDIRECT(mbuf) && > rte_mbuf_refcnt_read(rte_mbuf_from_indirect(mbuf)) > 1)) { > > If this is a cloned packet, the refcnt will be 1. So you need to examine > the parent mbuf to see if other clones exist. > The problem is that indirect buffers probably can't be overwritten because of lack of headroom. Actually, why not push the problem into the pktmbuf_headroom logic?