From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 917DB1B3A5 for ; Fri, 5 Apr 2019 01:54:56 +0200 (CEST) Received: by mail-pg1-f194.google.com with SMTP id 85so2036636pgc.3 for ; Thu, 04 Apr 2019 16:54:56 -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=tqsOW1rPocxVwIUlVd+0aHFlqrUVhZ+lDNiNL7QyiS8=; b=nmnwe0URnDN+q5EGQhgRS+sWb73BvJcR3LrRMNbhJglLm5ramSMPVrHE26QQt+POA+ r1zLeuyfqld9Qg32C74vRg9vN639oR8QBQStw6+sBkFEShfwcDSqlcRf3mbO0CH27ZxZ AKkvLeAEs9pEwt1CmOrHgvMXGAbLscrlEY5105dZ3xt3EuOoq1I6NG5NlLE4w6+bvBAp SoLGMTrENpf4SRgNKP+ErvCogH9N5Zl+Yv0w9XYh73CF7RnsJTHQy8M5nDF0+nws7M0B azqkIjwDnwmGvu30WECDyhTwCm0k5HFCxfXacFVNhBxbenWOjaQbg+3aQ6JJjIBkj/LE FK1g== 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=tqsOW1rPocxVwIUlVd+0aHFlqrUVhZ+lDNiNL7QyiS8=; b=JfuuD9U1IawrBkolRclhe40IaXON+eDoxTz7y6icLMkTj+2DAjHXRb5Fig//H13qYA KSYiRwKtg0LGK4C7Hf+jxzL/yRHYEPmY8JOw83gvXpsGhphCJELPatRaPAQtcAaD7hGw W/5HsxWDg13+tSQ9WpTqqb+7VgcKiPVcWBEYsUr8oUJ6kUQEtjwumlwmSmB8iXvUggZ+ 3gXMu9/LlKQuyu6YIg6Qn5cBRzv83Lu8ixgQ3zRJsa3s5iV7tFd86OeOGgwCyzm0QBmJ kGY6nv5cOdNdaWhNnwBt9k/h2gou0E72mUoVA7BS0X29Chod+ZHcHNCIpMQCNMLSnkW5 J8Wg== X-Gm-Message-State: APjAAAUhRv1r2k+kmxmqvkFCObEwfn18Yx3AbSrxTkrXVLYpY/vOzZ0l WSkocng4jToiR+rnU0byuLtGBw== X-Google-Smtp-Source: APXvYqxRg4QR9QYOIsb0HAlE7sA0mPTUgGRPd3MOx23NGQJU8Mt9Q+AAihN7+px1CVfI6KmoStRhVQ== X-Received: by 2002:a63:c944:: with SMTP id y4mr8369030pgg.257.1554422094768; Thu, 04 Apr 2019 16:54:54 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([167.220.104.127]) by smtp.gmail.com with ESMTPSA id c1sm27747319pfd.114.2019.04.04.16.54.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Apr 2019 16:54:54 -0700 (PDT) Date: Thu, 4 Apr 2019 16:54:49 -0700 From: Stephen Hemminger To: Chas Williams <3chas3@gmail.com> Cc: dev@dpdk.org, Stephen Hemminger Message-ID: <20190404165449.0f7ea879@shemminger-XPS-13-9360> In-Reply-To: References: <20190328205322.852-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC v2] 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: Thu, 04 Apr 2019 23:54:56 -0000 On Sat, 30 Mar 2019 08:41:33 -0400 Chas Williams <3chas3@gmail.com> wrote: > Unfortunately, I think the complete fix is more complicated than this. > Drivers that use rte_vlan_insert don't anticipate that the mbuf might > change and that (hardware) transmit can fail. > > They make a copy of the mbuf pointer from the incoming transmit list > and don't update the original if rte_vlan_insert creates a new mbuf. > If transmit fails, the application needs to be the given the new mbuf > for re-transmission or freeing. > > On 3/28/19 4:53 PM, Stephen Hemminger wrote: > > If mbuf is shared then rte_vlan_insert() would clobber the original > > Ethernet header. The changed version handles this by getting > > an mbuf that will hold the new Ethernet and VLAN header followed > > by another mbuf (cloned) for the data. > > > > Fixes: c974021a5949 ("ether: add soft vlan encap/decap") > > Signed-off-by: Stephen Hemminger The virtio driver is buggy, it saves original mbuf and doesn't handle rewrite. Dpaa2 is fine, should never happen since it checks refcnt etc. Netvsc PMD is using this on rx path and is safe. AF_packet PMD should work fine as well. So virtio is the one that needs fixing 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 07843A0679 for ; Fri, 5 Apr 2019 01:54:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B3BE71B3A7; Fri, 5 Apr 2019 01:54:58 +0200 (CEST) Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 917DB1B3A5 for ; Fri, 5 Apr 2019 01:54:56 +0200 (CEST) Received: by mail-pg1-f194.google.com with SMTP id 85so2036636pgc.3 for ; Thu, 04 Apr 2019 16:54:56 -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=tqsOW1rPocxVwIUlVd+0aHFlqrUVhZ+lDNiNL7QyiS8=; b=nmnwe0URnDN+q5EGQhgRS+sWb73BvJcR3LrRMNbhJglLm5ramSMPVrHE26QQt+POA+ r1zLeuyfqld9Qg32C74vRg9vN639oR8QBQStw6+sBkFEShfwcDSqlcRf3mbO0CH27ZxZ AKkvLeAEs9pEwt1CmOrHgvMXGAbLscrlEY5105dZ3xt3EuOoq1I6NG5NlLE4w6+bvBAp SoLGMTrENpf4SRgNKP+ErvCogH9N5Zl+Yv0w9XYh73CF7RnsJTHQy8M5nDF0+nws7M0B azqkIjwDnwmGvu30WECDyhTwCm0k5HFCxfXacFVNhBxbenWOjaQbg+3aQ6JJjIBkj/LE FK1g== 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=tqsOW1rPocxVwIUlVd+0aHFlqrUVhZ+lDNiNL7QyiS8=; b=JfuuD9U1IawrBkolRclhe40IaXON+eDoxTz7y6icLMkTj+2DAjHXRb5Fig//H13qYA KSYiRwKtg0LGK4C7Hf+jxzL/yRHYEPmY8JOw83gvXpsGhphCJELPatRaPAQtcAaD7hGw W/5HsxWDg13+tSQ9WpTqqb+7VgcKiPVcWBEYsUr8oUJ6kUQEtjwumlwmSmB8iXvUggZ+ 3gXMu9/LlKQuyu6YIg6Qn5cBRzv83Lu8ixgQ3zRJsa3s5iV7tFd86OeOGgwCyzm0QBmJ kGY6nv5cOdNdaWhNnwBt9k/h2gou0E72mUoVA7BS0X29Chod+ZHcHNCIpMQCNMLSnkW5 J8Wg== X-Gm-Message-State: APjAAAUhRv1r2k+kmxmqvkFCObEwfn18Yx3AbSrxTkrXVLYpY/vOzZ0l WSkocng4jToiR+rnU0byuLtGBw== X-Google-Smtp-Source: APXvYqxRg4QR9QYOIsb0HAlE7sA0mPTUgGRPd3MOx23NGQJU8Mt9Q+AAihN7+px1CVfI6KmoStRhVQ== X-Received: by 2002:a63:c944:: with SMTP id y4mr8369030pgg.257.1554422094768; Thu, 04 Apr 2019 16:54:54 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([167.220.104.127]) by smtp.gmail.com with ESMTPSA id c1sm27747319pfd.114.2019.04.04.16.54.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Apr 2019 16:54:54 -0700 (PDT) Date: Thu, 4 Apr 2019 16:54:49 -0700 From: Stephen Hemminger To: Chas Williams <3chas3@gmail.com> Cc: dev@dpdk.org, Stephen Hemminger Message-ID: <20190404165449.0f7ea879@shemminger-XPS-13-9360> In-Reply-To: References: <20190328205322.852-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC v2] 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: <20190404235449.8Y9Gjj0Q0K8o3fCPY83QHMjsYTBsTLvPM_AbKN9q60Q@z> On Sat, 30 Mar 2019 08:41:33 -0400 Chas Williams <3chas3@gmail.com> wrote: > Unfortunately, I think the complete fix is more complicated than this. > Drivers that use rte_vlan_insert don't anticipate that the mbuf might > change and that (hardware) transmit can fail. > > They make a copy of the mbuf pointer from the incoming transmit list > and don't update the original if rte_vlan_insert creates a new mbuf. > If transmit fails, the application needs to be the given the new mbuf > for re-transmission or freeing. > > On 3/28/19 4:53 PM, Stephen Hemminger wrote: > > If mbuf is shared then rte_vlan_insert() would clobber the original > > Ethernet header. The changed version handles this by getting > > an mbuf that will hold the new Ethernet and VLAN header followed > > by another mbuf (cloned) for the data. > > > > Fixes: c974021a5949 ("ether: add soft vlan encap/decap") > > Signed-off-by: Stephen Hemminger The virtio driver is buggy, it saves original mbuf and doesn't handle rewrite. Dpaa2 is fine, should never happen since it checks refcnt etc. Netvsc PMD is using this on rx path and is safe. AF_packet PMD should work fine as well. So virtio is the one that needs fixing