From patchwork Tue Mar 13 15:07:22 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liran Alon X-Patchwork-Id: 885170 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@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=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="Hy+/Rm3K"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 400ysD3xntz9sRN for ; Wed, 14 Mar 2018 02:08:00 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751997AbeCMPHs (ORCPT ); Tue, 13 Mar 2018 11:07:48 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:60358 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbeCMPHr (ORCPT ); Tue, 13 Mar 2018 11:07:47 -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 w2DF7QQE195680; Tue, 13 Mar 2018 15:07:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=UiyAf2180sX5U4fLo2JEGF3dO/pniNFaA3z/f6Qe3tE=; b=Hy+/Rm3K9yP4kICN3sWb7ZcHdFKoaoEgSbxTP2Mb5Iaz/F8QJJADYnEUqxnH21PffDx2 HgJrlWN8dloJqedS1OJG6c2b80aIc3iRXZ5Y33ZUs95QPQwwZw9gqpm2bNxqNdie6JQs 8B0kRhD9DzzaaoGwLM5MO27qcUMQsUPK0BAHa6cgfvtfsMoAl2tPri6S184RnHrPfioL yN7qayH4KRszhcQt/JHPcHD9s8ceWiQ708CfLZ9bT22Zrjco4JHdSkiZgjxwCEwu9mC1 rDq+TwvENErODBwgq+c+jjWQsZqCnpYo5KqNNeuaU9pRzezPZct60NboiKUOhnHCHWv4 Fg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2gpgym00r8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Mar 2018 15:07:41 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2DF7edS019043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Mar 2018 15:07:41 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2DF7eaL016181; Tue, 13 Mar 2018 15:07:40 GMT Received: from liran-pc.ravello.local (/213.57.127.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Mar 2018 08:07:40 -0700 From: Liran Alon To: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: idan.brown@oracle.com, Liran Alon , Yuval Shaia Subject: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns Date: Tue, 13 Mar 2018 17:07:22 +0200 Message-Id: <1520953642-8145-1-git-send-email-liran.alon@oracle.com> X-Mailer: git-send-email 1.9.1 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8830 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-1803130179 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. Signed-off-by: Liran Alon Reviewed-by: Yuval Shaia Signed-off-by: Yuval Shaia --- 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) {