Received: by 10.213.65.68 with SMTP id h4csp1534553imn; Thu, 15 Mar 2018 02:23:41 -0700 (PDT) X-Google-Smtp-Source: AG47ELtKjEu4yDtHE8plbxg5OTRxfrNSXkDW2iknSV7mhoFpd7o3EYsCg3jKzfX5p/ZknuKRr5vC X-Received: by 2002:a17:902:2c43:: with SMTP id m61-v6mr7311416plb.387.1521105821832; Thu, 15 Mar 2018 02:23:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521105821; cv=none; d=google.com; s=arc-20160816; b=E/9nws7Ks4f2DFoNPxWR3yo7YmlgDfOevQNW8Rra9zpzhozXc6fomP/IqgnocFs3Xx Fh4v8hqboy+6FAKzIcJtB31j2/hKxBd2XE9ASVyLs7krz8FHo5o8Ioaj9hhPYZQIE850 EuzHB5MOdVWfFQVkVhPTOTiIub5dZ/QnMNWSEcWtoJgZIwjUllQgH1d2LMmRxOqLz6Tz O9RhfgypKvgbbLTFEzscukuL7nkYHm7eSAP7qSuLz05PDPgqKP9Y82x+FXXjC87yaXKr dUEZOL893NoLiOoEpS2bEoEUdnpmjKX6mRxYPAWI4hkL4dSqn/FaECB3QmOvvW0u5t2G l7lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=FOJXqwzC4BWpsJlUsmkHaDQAYSDpz0mQig7ehabadx8=; b=rVkwyIRrmGGWU9ozf/W5pHx7n8qYX9aNfMqn5fkzEyK3+tJ7EEcgvU4vkzyccitIzu dilPjV+tn6vqoLAWxKD/aJ/QXghRYE/QEhXu3AND8trWvPDIEVE1Xpmd0w839r7D75nV ira1X0RQq2+38Egms+06A1fy9cc/3QyFbuXt9nazGizFiYiPVcoLALe89jcRaGzlgpLi 9hgAfOqfi2Us3HQ88jJTEbLX6wS/NX4zWFKEneOkTwOmvaybXGomSKFCgEKcTuOl4NQm i0aIoPNUyUDtO4+ldbZ8ZibEMcUR3ygsja6nKp/Vr7bEoqJr90cud8naWglP+mjTYQ5c bvSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tTaN8gCp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13si3491183pfh.217.2018.03.15.02.23.27; Thu, 15 Mar 2018 02:23:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tTaN8gCp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751682AbeCOJWH (ORCPT + 99 others); Thu, 15 Mar 2018 05:22:07 -0400 Received: from mail-wr0-f182.google.com ([209.85.128.182]:39826 "EHLO mail-wr0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbeCOJWF (ORCPT ); Thu, 15 Mar 2018 05:22:05 -0400 Received: by mail-wr0-f182.google.com with SMTP id k3so7471453wrg.6; Thu, 15 Mar 2018 02:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FOJXqwzC4BWpsJlUsmkHaDQAYSDpz0mQig7ehabadx8=; b=tTaN8gCpH0ZtzK7QuaMrzlRWj3HIsRHdz+40mfP/BuFSatDgTjqhF48OqaYM/LDjX4 W83xAzBs8Vt8KNOt+DBhXQNiATgKaPO2XNgrWMNIumWu16ZqS4GoA2GusgqC13x6VC5R eBHAndJqXWxir6sM8PbECZ53B1DZdBKYfDdoYKlJy4IjLbszq9iI7shMwTtm03u/1FZG baPGYyY8oo3hDzoNTCPDmRQgzSPHB50GlJbGRPwBvHcuhIoL275Q3pU8S5KE+/5YeRFB LuZbkb7UD3C2wt+5lEa7AfAmYbf1Tb0eIoHxRp9tD4LJXmg8A/7z9vuP6JFElYOuJSh4 IWnQ== 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=FOJXqwzC4BWpsJlUsmkHaDQAYSDpz0mQig7ehabadx8=; b=jj0/aLiizpY0Zf+JMj815xrS1O9NV8tvNq5CqSgFzjRCCLvZDtULt45OP705GbHKEN WXE9neLHnHtHV3TABoGyI9wD2o/x8CZrir9iiSaZGiPLz7ce5niC62payXqwC5ScAreI MHV7jyPz6WOKyQn4UpZ5uHMjrvU/DNx7InRFtg8U7JAk1oQtPotpVfDuGlcs4BxYAcWI RSEbE45VbmE9QCvRtCNbAos7P7ZkfISgplLTfDetqaLzkV22NKpw3iRC6ml8c8OPnHKf IoNZEWVq7gHdKE1/GSSsX+QuYYSDRkfmKXHSwvRCXDB6TNyv9c2I8OYSdW+MULeLz2q1 TEOg== X-Gm-Message-State: AElRT7Eoes1u4eCElJ0tf12vay8eOmeSjVCYqpPVFfRMV08N3IZDlEfx jP2+eIgFftr0mUCeOj8vb88= X-Received: by 10.223.182.16 with SMTP id f16mr6195209wre.51.1521105723798; Thu, 15 Mar 2018 02:22:03 -0700 (PDT) Received: from halley ([141.226.179.122]) by smtp.gmail.com with ESMTPSA id v23sm2806196wmc.22.2018.03.15.02.22.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 02:22:02 -0700 (PDT) Date: Thu, 15 Mar 2018 11:21:49 +0200 From: Shmulik Ladkani To: Liran Alon , Daniel Borkmann Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, idan.brown@oracle.com, Yuval Shaia Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns Message-ID: <20180315112150.58586758@halley> In-Reply-To: <1520953642-8145-1-git-send-email-liran.alon@oracle.com> References: <1520953642-8145-1-git-send-email-liran.alon@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon wrote: > Before this commit, dev_forward_skb() always cleared packet's > per-network-namespace info. Even if the packet doesn't cross > network namespaces. > > The comment above dev_forward_skb() describes that this is done > because the receiving device may be in another network namespace. > However, this case can easily be tested for and therefore we can > scrub packet's per-network-namespace info only when receiving device > is indeed in another network namespace. > > Therefore, this commit changes ____dev_forward_skb() to tell > skb_scrub_packet() that skb has crossed network-namespace only in case > transmitting device (skb->dev) network namespace is different then > receiving device (dev) network namespace. Assuming the premise of this commit is correct, note it may not act as intended for xnet situation in ipvlan_process_multicast, snip: nskb->dev = ipvlan->dev; if (tx_pkt) ret = dev_forward_skb(ipvlan->dev, nskb); else ret = netif_rx(nskb); as 'dev' gets already assigned to nskb prior dev_forward_skb (hence in ____dev_forward_skb both dev and skb->dev are the same). Fortunately every ipvlan_multicast_enqueue call is preceded by a forced scrub; It would be future-proof to not assign nskb->dev in the dev_forward_skb case (assign it only in the netif_rx case). Regarding the premise of this commit, this "reduces" the ipvs/orphan/mark scrubbing in the following *non* xnet situations: 1. mac2vlan port xmit to other macvlan ports in Bridge Mode 2. similarly for ipvlan 3. veth xmit 4. l2tp_eth_dev_recv 5. bpf redirect/clone_redirect ingress actions Regarding l2tp recv, this commit seems to align the srubbing behavior with ip tunnels (full scrub only if crossing netns, see ip_tunnel_rcv). Regarding veth xmit, it does makes sense to preserve the fields if not crossing netns. This is also the case when one uses tc mirred. Regarding bpf redirect, well, it depends on the expectations of each bpf program. I'd argue that preserving the fields (at least the mark field) in the *non* xnet makes sense and provides more information and therefore more capabilities; Alas this might change behavior already being relied on. Maybe Daniel can comment on the matter. Regards, Shmulik