From patchwork Thu May 16 21:54:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 1100747 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=networkplumber.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="zZ6dq6JY"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 454lZF6pYxz9s9N for ; Fri, 17 May 2019 07:54:29 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728885AbfEPVy2 (ORCPT ); Thu, 16 May 2019 17:54:28 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:45540 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728871AbfEPVy2 (ORCPT ); Thu, 16 May 2019 17:54:28 -0400 Received: by mail-pg1-f193.google.com with SMTP id i21so2187739pgi.12 for ; Thu, 16 May 2019 14:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jW23EVTaONU8fGl2rO/gh8exrFRja4BdXSBKXyg60v0=; b=zZ6dq6JYsNCTLilh4tdiqHrmv23xzcGSKF4r/LqIMcfbTyNphvxWoH9D2upjSAHuz0 e9u/x6/0LdA6y7vansZpzlI25i5pXMmuex74Y0zuhc6kkxgG5UXePl8Mkqw3MZEb8Q1K fpPH7OlTG6MWtYaTTmh1Q6NAkCjEC7go7jEA+EP+cYezRte27zS3LRUfH1ymuFXKM6Ke iComxjPK+RX3NZgq4QGr3wNs4OgEzYvkfQeLDUFWkEIJ8b9TGMDeD+6DZN+ec7zigPMM kC6e8ypK+ANYfp2gFTL+W4KOxbt/pHRiS3C2Km5XDfUepuALZA8Fk6lE5mVizH7wd791 WrNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jW23EVTaONU8fGl2rO/gh8exrFRja4BdXSBKXyg60v0=; b=tssGb05XuVCjL/tygURhIOtOdtrr1TgMKRWjGxUx5tpOBT6H50s7E88SmYniABA016 1lpTzoonL1hn1gVyasAbaECDzIt1cffp0gqWDlCoPQihBhSNbfEnvWRghjtsg7n0HULq 6EQ2UcjHAlg0HkHy5VIyvSR8JJDxRq9o/9rx9nqnwo7A+zWzStAB11kaOfjScps1QaaX SsxXkqOH+8aGdwKdMkMGGYXJxnur3cOk45rCvbxEE7VrbnxZqYOYvcII/Cc6HJl1JVNg J5yElCcDWVZEZU3codqazzZ/IsvyDhiuw4UtkIfj8N3yK+Lr4D6kGaty0i/Rm6AyygZ9 r+Kw== X-Gm-Message-State: APjAAAUzyx4gW0a9AcH7a70eWn5R0lLEifPAkUtKC4wKWk9GzC621TCn +tcXtQig0qa/wFQOXM6RuQkmTQ== X-Google-Smtp-Source: APXvYqx2B9kBrdR04F1t4i1XgaAah3bmKTotNbx3FQ2RNR9kO4Y5NeCwckRaxlUBDkYf1mqjeiOSIg== X-Received: by 2002:a62:1b8a:: with SMTP id b132mr56143116pfb.19.1558043667786; Thu, 16 May 2019 14:54:27 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id d15sm19842506pfm.186.2019.05.16.14.54.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 14:54:26 -0700 (PDT) From: Stephen Hemminger X-Google-Original-From: Stephen Hemminger To: netdev@vger.kernel.org, davem@davemloft.net Cc: xdp-newbies@vger.kernel.org, bpf@vger.kernel.org, Stephen Hemminger Subject: [PATCH net 1/3] netvsc: unshare skb in VF rx handler Date: Thu, 16 May 2019 14:54:21 -0700 Message-Id: <20190516215423.14185-2-sthemmin@microsoft.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190516215423.14185-1-sthemmin@microsoft.com> References: <20190516215423.14185-1-sthemmin@microsoft.com> MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-Id: netdev.vger.kernel.org The netvsc VF skb handler should make sure that skb is not shared. Similar logic already exists in bonding and team device drivers. This is not an issue in practice because the VF devicex does not send up shared skb's. But the netvsc driver should do the right thing if it did. Fixes: 0c195567a8f6 ("netvsc: transparent VF management") Signed-off-by: Stephen Hemminger --- drivers/net/hyperv/netvsc_drv.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 06393b215102..9873b8679f81 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2000,6 +2000,12 @@ static rx_handler_result_t netvsc_vf_handle_frame(struct sk_buff **pskb) struct netvsc_vf_pcpu_stats *pcpu_stats = this_cpu_ptr(ndev_ctx->vf_stats); + skb = skb_share_check(skb, GFP_ATOMIC); + if (unlikely(!skb)) + return RX_HANDLER_CONSUMED; + + *pskb = skb; + skb->dev = ndev; u64_stats_update_begin(&pcpu_stats->syncp); From patchwork Thu May 16 21:54:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 1100751 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=networkplumber.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="gHkbTo/d"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 454lZJ6nPWz9s7h for ; Fri, 17 May 2019 07:54:32 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728899AbfEPVyb (ORCPT ); Thu, 16 May 2019 17:54:31 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:44590 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728890AbfEPVy3 (ORCPT ); Thu, 16 May 2019 17:54:29 -0400 Received: by mail-pf1-f196.google.com with SMTP id g9so2522515pfo.11 for ; Thu, 16 May 2019 14:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1E3N0zT9A+r2im6QpOgDPD+XgR8M/OLuBEDLlf3Z7+c=; b=gHkbTo/dzg62EsHuFOEqzE4zD0Awx6QMgcAVIz/QDckgP8FbVYM+OnrKQVNxdWE0gX QKCSUSA/5MtU2Sh8txLOvLtyG4AbSahniQnaAFLf/nYHtbFzkha6QBUUHIwqdaAQ4Kgk 1deRntqeIqPhsdF+aTx7HcXFte1XoPJz3t73ctR67DoLXakKCZLv/0Fvy4UTaf48V38i Qg4zypj/7GDSaP8zDKz2rHdFXDEB4hsddy7VtJ1Yu/ZTEN49nhygcMkJCpvXO+L2Z5pw tCDFBuEKrBZaZMCL2KnVBs5qRKvhGlpGEP/Pss70wox83tzVtngnivANiEWDIb2Bt53s z9iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1E3N0zT9A+r2im6QpOgDPD+XgR8M/OLuBEDLlf3Z7+c=; b=Twb6qZpR+4+S0I0FNaer5ElymHYdq1siFh3f+4CQtqrjeM2VSOXKUp/a0trk81cH4Q gNu4IkF+xhGeFuqZaQ2GMo/w9lShaP/4VQ78ILZqt9C8gLkx5QgxdEStLJKeFQ2fYDyQ TGED5rvnMGXAkc34Hwogj1csRurlx62B8k+iv1km2wOUm74oPQqnZFW+ExP9P2Yj1Vap z647tUZVAoMETIGSxR8Hnq2hKVJtaETBlOoC5jk+X1r0Ao/MJxfjZNSU/4n0Z9omIBFy lyDairsLQQor+nbRzURQkfBpEiFCJGYEEtwFyQn0TvPNKfL8vsoJb742DkDpLqhbiZWd 1Ihw== X-Gm-Message-State: APjAAAXXN56eWZUfxOvv3mzr1wkXqHKoLr9O9ZhYR7tLGG+4Hqipz375 AiYK23Nrg1AlYQCrm6ZFoxeJ5g== X-Google-Smtp-Source: APXvYqyFTs+tyVssS57cMOZTZJEMcnxAqM0IxUaMpyARtuJ/MrI3oWy5+iENt2ct906kPow0o/zKJw== X-Received: by 2002:a62:528b:: with SMTP id g133mr56806059pfb.246.1558043668893; Thu, 16 May 2019 14:54:28 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id d15sm19842506pfm.186.2019.05.16.14.54.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 14:54:28 -0700 (PDT) From: Stephen Hemminger X-Google-Original-From: Stephen Hemminger To: netdev@vger.kernel.org, davem@davemloft.net Cc: xdp-newbies@vger.kernel.org, bpf@vger.kernel.org, Stephen Hemminger , Jason Wang Subject: [PATCH net 2/3] net: core: generic XDP support for stacked device Date: Thu, 16 May 2019 14:54:22 -0700 Message-Id: <20190516215423.14185-3-sthemmin@microsoft.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190516215423.14185-1-sthemmin@microsoft.com> References: <20190516215423.14185-1-sthemmin@microsoft.com> MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-Id: netdev.vger.kernel.org When a device is stacked like (team, bonding, failsafe or netvsc) the XDP generic program for the parent device is not called. In these cases, the rx handler changes skb->dev to its own in the receive handler, and returns RX_HANDLER_ANOTHER. Fix this by calling do_xdp_generic if necessary before starting another round. Review of all the places RX_HANDLER_ANOTHER is returned show that the current devices do correctly change skb->dev. There was an older patch that got abandoned that did the same thing, this is just a rewrite. Suggested-by: Jason Wang Fixes: d445516966dc ("net: xdp: support xdp generic on virtual devices") Signed-off-by: Stephen Hemminger Acked-by: Jason Wang --- net/core/dev.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/net/core/dev.c b/net/core/dev.c index 108ac8137b9b..9165fd3c9e90 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4921,6 +4921,16 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc, ret = NET_RX_SUCCESS; goto out; case RX_HANDLER_ANOTHER: + if (static_branch_unlikely(&generic_xdp_needed_key)) { + struct bpf_prog *xdp_prog; + + xdp_prog = rcu_dereference(skb->dev->xdp_prog); + ret = do_xdp_generic(xdp_prog, skb); + if (ret != XDP_PASS) { + ret = NET_RX_SUCCESS; + goto out; + } + } goto another_round; case RX_HANDLER_EXACT: deliver_exact = true; From patchwork Thu May 16 21:54:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 1100750 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=networkplumber.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="IcpzO48F"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 454lZJ2cYjz9s4Y for ; Fri, 17 May 2019 07:54:32 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728901AbfEPVyb (ORCPT ); Thu, 16 May 2019 17:54:31 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:39620 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728899AbfEPVya (ORCPT ); Thu, 16 May 2019 17:54:30 -0400 Received: by mail-pl1-f196.google.com with SMTP id g9so2268809plm.6 for ; Thu, 16 May 2019 14:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=xuy+4KeQUeW3R7SNZ+HYiTwXxQ5E43mgDn+NwskHEzs=; b=IcpzO48FvAJ670uKYLzhbsBgfyBFMhvCUcuBw6bCpeLGFuiE/+Koz9cZ+cDKHugSuh dbFUDbXbqXa4me+xIhFnv+8VFY0Ox2jf2KZrPkGEPPmYckaqOBBKGz3ETPiMFAZGDN3w dOyNu4ImP+vRTD66t/z3Qm//GvhRW/oLChJ9CHQWZ/tWyTEPjr8uLtzLfv5925y5yWyj 1lZQYsUQMVBKVlEZDti1fSZNghCV8NG8tbxZpwo9Q8IQuT78eNtS91T+eMoOjqAi9V/n ZHnJ109iB+FRb7wEPTHJw5upLIIZP/XfQJcMswQFJiii5PTlM4wI0SxXT0kGBav0E+w4 e0VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xuy+4KeQUeW3R7SNZ+HYiTwXxQ5E43mgDn+NwskHEzs=; b=laiyxuD9g8STe6KeF+0aNYh+GsPyAsXWyuh0DMRxWrGxwNzz8NmWFRZ7mYybn712Gy NCDvcOVMk1bO6dduJjymAEwbNF/lIJM7H90ad7ED/5IvMgTj1qgzUy5N6dl4OoWLp0K5 9k2rOmc1TU3d8AZo8YXNLR5LjmBaLpUf8R7i9djABgOpUeGSHusMlqZZQx1R7Wi/7V7F m8QCLku2BnamZLoBAmf7Ca9+VS5sm2gFdRiH9frV1su/ZpK9yVtUbvvl7hLF76K/RaRZ tuh7z9c+1u8HZYY0apm+Z73PLNN+t5k13CIVgD80gIhOd4oDxZcMSGfXgm95P6p9in2I y3VQ== X-Gm-Message-State: APjAAAXXdj3/+VrTKJvC1estNm8ZVdIBDT6gTPl5N7L7bsDYpQ2p4M32 9IXFcLHrM5U95Rzq5PnqQl73Ow== X-Google-Smtp-Source: APXvYqze6mU3ZczpGFKB7O1KBUB7ctB0WhYsf9IFGEuMKNxecLDDaXlHc4sSU1Ax4HNfYvY4GRIPDg== X-Received: by 2002:a17:902:2f03:: with SMTP id s3mr26178463plb.203.1558043669895; Thu, 16 May 2019 14:54:29 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id d15sm19842506pfm.186.2019.05.16.14.54.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 14:54:29 -0700 (PDT) From: Stephen Hemminger X-Google-Original-From: Stephen Hemminger To: netdev@vger.kernel.org, davem@davemloft.net Cc: xdp-newbies@vger.kernel.org, bpf@vger.kernel.org, Stephen Hemminger Subject: [PATCH net 3/3] netdevice: clarify meaning of rx_handler_result Date: Thu, 16 May 2019 14:54:23 -0700 Message-Id: <20190516215423.14185-4-sthemmin@microsoft.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190516215423.14185-1-sthemmin@microsoft.com> References: <20190516215423.14185-1-sthemmin@microsoft.com> MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-Id: netdev.vger.kernel.org Make the language in comment about rx_handler_result clearer. Especially the meaning of RX_HANDLER_ANOTHER. Replace use of "should" with "must" to be in line with common usage in standards documents. Signed-off-by: Stephen Hemminger --- include/linux/netdevice.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 44b47e9df94a..56f613561909 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -374,10 +374,10 @@ typedef enum gro_result gro_result_t; /* * enum rx_handler_result - Possible return values for rx_handlers. - * @RX_HANDLER_CONSUMED: skb was consumed by rx_handler, do not process it - * further. - * @RX_HANDLER_ANOTHER: Do another round in receive path. This is indicated in - * case skb->dev was changed by rx_handler. + * @RX_HANDLER_CONSUMED: skb was consumed by rx_handler. + * Do not process it further. + * @RX_HANDLER_ANOTHER: skb->dev was modified by rx_handler, + * Do another round in receive path. This is indicated in * @RX_HANDLER_EXACT: Force exact delivery, no wildcard. * @RX_HANDLER_PASS: Do nothing, pass the skb as if no rx_handler was called. * @@ -394,20 +394,20 @@ typedef enum gro_result gro_result_t; * Upon return, rx_handler is expected to tell __netif_receive_skb() what to * do with the skb. * - * If the rx_handler consumed the skb in some way, it should return + * If the rx_handler consumed the skb in some way, it must return * RX_HANDLER_CONSUMED. This is appropriate when the rx_handler arranged for * the skb to be delivered in some other way. * * If the rx_handler changed skb->dev, to divert the skb to another - * net_device, it should return RX_HANDLER_ANOTHER. The rx_handler for the + * net_device, it must return RX_HANDLER_ANOTHER. The rx_handler for the * new device will be called if it exists. * - * If the rx_handler decides the skb should be ignored, it should return + * If the rx_handler decides the skb should be ignored, it must return * RX_HANDLER_EXACT. The skb will only be delivered to protocol handlers that * are registered on exact device (ptype->dev == skb->dev). * * If the rx_handler didn't change skb->dev, but wants the skb to be normally - * delivered, it should return RX_HANDLER_PASS. + * delivered, it must return RX_HANDLER_PASS. * * A device without a registered rx_handler will behave as if rx_handler * returned RX_HANDLER_PASS.