Received: by 10.213.65.68 with SMTP id h4csp445175imn; Tue, 13 Mar 2018 09:15:53 -0700 (PDT) X-Google-Smtp-Source: AG47ELt2ZhVErtxvYoQd6tHGe/mGjzTxSF/Dl16r+ETT0e68TWFH/5u1nIFdrPIAI9eKGstn6pg0 X-Received: by 2002:a17:902:b20f:: with SMTP id t15-v6mr1031404plr.349.1520957753380; Tue, 13 Mar 2018 09:15:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520957753; cv=none; d=google.com; s=arc-20160816; b=t06K8YB5lOkVI9neNPOsZ6S7EqKK+kR+eCscXJEdBkfoAcDkC1Wn3KPSf7nIPxPlKq Yke6mx6J3LCqlt7hX3NWrFC1z3a2b0jM/4MiVTr14ahhd8vHd6mL4uqiMlvdl8YfNDYU KHsNT4xg7Nj5Vn1zxd/kaUYi618d4B6I6Mjuq1oMe8hXF22iBa/jkQZfx604OEWk9Yc5 7sye3ScUxxHgnSgD1eL0PYVX2XLPWnOp0Qar50N+sqkimkGkf54ui1eWbEkVR06dEkGQ KUbBNyMvnFDEoUyXWjGhpFS8MPK9C7mYxqdDAruJ7ccppLRlHQR7rA3mhJha1hgcQqRl J1oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=NkAWPnj4bomWSH2CNUQoQF1BorYEWV4/NFvMSpynjJM=; b=s+vIp7RzjFmmGQX3zJqek38bRsJTa5VKKF0TfGinvJdYyqQbyaRfm87kE8Iy/x4ebQ abkzGg7tP95NSFJHIsqa25hiR/l4wy0u9w8zRBYsk99lxEFnAQiiIbXDNjggTf6Slq7n uGGFmCw2Vik9D/aztt9RtZfCbIKdITOG54Pxrn2fk+vMmlf2t++DAI5569FsFCmAqgWM DhvABUYjqEzKLm13SIyhge/BIxrBEGLb9D3axIOovRF/Jo28CmZuFeb541jbv6usrQYo dhM1/mhNDg9+HpEo1G220S3zP3Pe+WOOKfdMn3sxj3IHm/VNYePAyAIY6EuFHgutk+Dm lQng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=e8iFYnRX; 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=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t63si262967pgt.745.2018.03.13.09.15.39; Tue, 13 Mar 2018 09:15:53 -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=@oracle.com header.s=corp-2017-10-26 header.b=e8iFYnRX; 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=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934162AbeCMQOR (ORCPT + 99 others); Tue, 13 Mar 2018 12:14:17 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:34456 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932901AbeCMQNz (ORCPT ); Tue, 13 Mar 2018 12:13:55 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2DGBvhe064465; Tue, 13 Mar 2018 16:13:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2017-10-26; bh=NkAWPnj4bomWSH2CNUQoQF1BorYEWV4/NFvMSpynjJM=; b=e8iFYnRXJInLBooIT+hEGGXvGDZVcdqR/cYZDt2zbHStshZ8MUT/tGDBJP1Eqc8kBk7D sZfHOCwWLhhUUp0P+MuHHlRPs8wG43ZPTj1sbXr8W9LRat4qla/CYnUx2W9NouRaBJ0r zgduPTxB6ZUB05fqpkoN4fm+xYHgZuh+lKrC6sLvJj3gbFoc3Gof9G4Qf/YvqEOLky12 7Unr/FvDwrdLgbvNwj9QYv+L1kI59rAOiIujyTUSj9kXnfYMKq/r7r8mq9QuGt6CECOa W5Ax1R6Ssg8Y3tP4iHbG/XgnqlJ3mU2BLEUdmfKq8vTziv2FHXhzChZDd9BK3EwEHP+C iA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2gpgym0gsb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Mar 2018 16:13:53 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2DGDqTG021135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Mar 2018 16:13:52 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2DGDpda031036; Tue, 13 Mar 2018 16:13:52 GMT Received: from yuvallap (/77.138.186.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Mar 2018 09:13:51 -0700 Date: Tue, 13 Mar 2018 18:13:46 +0200 From: Yuval Shaia To: Liran Alon Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, idan.brown@oracle.com Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns Message-ID: <20180313161345.GC4023@yuvallap> References: <1520953642-8145-1-git-send-email-liran.alon@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1520953642-8145-1-git-send-email-liran.alon@oracle.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8831 signatures=668690 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803130189 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 13, 2018 at 05:07:22PM +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. > > An example of a netdev that use skb_forward_skb() is veth. > Thus, before this commit a packet transmitted from one veth peer to > another when both veth peers are on same network namespace will lose > it's skb->mark. The bug could easily be demonstrated by the following: > > ip netns add test > ip netns exec test bash > ip link add veth-a type veth peer name veth-b > ip link set veth-a up > ip link set veth-b up > ip addr add dev veth-a 12.0.0.1/24 > tc qdisc add dev veth-a root handle 1 prio > tc qdisc add dev veth-b ingress > tc filter add dev veth-a parent 1: u32 match u32 0 0 action skbedit mark 1337 > tc filter add dev veth-b parent ffff: basic match 'meta(nf_mark eq 1337)' action simple "skb->mark 1337!" > dmesg -C > ping 12.0.0.2 > dmesg > > Before this change, the above will print nothing to dmesg. > After this change, "skb->mark 1337!" will be printed as necessary. Hi Liran, > > Signed-off-by: Liran Alon > Reviewed-by: Yuval Shaia > Signed-off-by: Yuval Shaia I did not earned the credits for SOB, only r-b. Yuval > --- > include/linux/netdevice.h | 2 +- > net/core/dev.c | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index 5eef6c8e2741..5908f1e31ee2 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -3371,7 +3371,7 @@ static __always_inline int ____dev_forward_skb(struct net_device *dev, > return NET_RX_DROP; > } > > - skb_scrub_packet(skb, true); > + skb_scrub_packet(skb, !net_eq(dev_net(dev), dev_net(skb->dev))); > skb->priority = 0; > return 0; > } > diff --git a/net/core/dev.c b/net/core/dev.c > index 2cedf520cb28..087787dd0a50 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -1877,9 +1877,9 @@ int __dev_forward_skb(struct net_device *dev, struct sk_buff *skb) > * start_xmit function of one device into the receive queue > * of another device. > * > - * The receiving device may be in another namespace, so > - * we have to clear all information in the skb that could > - * impact namespace isolation. > + * The receiving device may be in another namespace. > + * In that case, we have to clear all information in the > + * skb that could impact namespace isolation. > */ > int dev_forward_skb(struct net_device *dev, struct sk_buff *skb) > { > -- > 1.9.1 >