Received: by 10.213.65.68 with SMTP id h4csp566569imn; Tue, 20 Mar 2018 09:47:03 -0700 (PDT) X-Google-Smtp-Source: AG47ELuuTTr5DpY1BuSFOx2HJAJzClOnOI5U5CwUufV7OP0LOx3DyBcBf6dSPhjYMA5+tdonE1m0 X-Received: by 10.98.15.137 with SMTP id 9mr14229358pfp.216.1521564423873; Tue, 20 Mar 2018 09:47:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521564423; cv=none; d=google.com; s=arc-20160816; b=MH67nFqYUit3HuB0gKgH5rQU9dZcBobBSokPQkMBQTu93vDRvm1i0IMay3bFs/2zFo t43siWR9C2kDvT0G6amvTTuNzgf4EjGYf0pLbBn/RlezM4GnoM4j6ttAgfpA74VYvlqe 7ZiFPmpb/7VWhNVp5M8rODUdUKeh5P7P7f1kef3sLTD0THoP+jV9DXLrTN7IJ4AEVH9p ryW3VHdkd7WcTsgkg1Xt4u2MtDhyDYXMICk9ec0mbhCb4Fr2H9m0dJuSdC3Mnm3g2K7z o9lo1Zfb8cs0EFdlCtojTQggYYs34YPBiVQOfrPcWCtK1uZiGSoVPnxthqC45vbc7kfX rTsg== 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:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:dkim-signature:arc-authentication-results; bh=V9FippflE7B23HTKZSXI0e7IpS5uzoiQ7RBsDayuqww=; b=hSTpDuYjADq0g2fT9mIJlliLkcyW8+MWCiBsfcriYiqHnhOcp90mnd3ntOYQsp8U1m W85jsiZhxXn/3ciToDnxsY6fJ1QAnkYP85Tw/nZq2miMdlWrdbHu0NRLarqg6Kx6L3nq p877w83mDF/3WQnuyYd9WrUMyhDmFm4cbWgK2OMz1mfufJOLx5LTpw+EQgUXUvMd2Pm/ syDvUtgqVjgK4O5YHc3nH/yZ49rIDkmYHqu7LzB10NBGLJfKnM1D0Cpn/zMkTBbo7HkK zTb3+4HDvlC8AJrK6cjqKrcEJzVKh2SjRf7lEW3Rf8YM5we02jV20dHygs2ocSLxZJkB rMgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=aStWYqnl; 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 u8-v6si2066442plr.50.2018.03.20.09.46.49; Tue, 20 Mar 2018 09:47:03 -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=aStWYqnl; 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 S1752031AbeCTQpa (ORCPT + 99 others); Tue, 20 Mar 2018 12:45:30 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:45016 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728AbeCTQpY (ORCPT ); Tue, 20 Mar 2018 12:45:24 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2KGfosp168448; Tue, 20 Mar 2018 16:45:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=V9FippflE7B23HTKZSXI0e7IpS5uzoiQ7RBsDayuqww=; b=aStWYqnlQP2WRd4uhBCLZDmzSizf5442DwHOjWDcsY2ijlwhDKZVMuNlFq9fgxZC2/Hp 2fqPKHk6HkcHlOgfCAoc1KQvc+3IX3QdoEBt7wP2dE32W3MJClaM4tJqwh+W4NqwDmr1 AdHHuuIn5tAOfXwV/izGy4eOFZxicTFGumc93IqU55h1rKyd4GvOSHQ+fraQjI8HY8bG iBN6K1Oj/plyzw7+aGBdT2t/GPWFIJ6JCfexyIjqpkpwYC+va5NLNnHvUiV/LAQZHD1U l98W4AGqJvsW6JFtdNCMVilI1jYUr45+qMspBAIS8x0O+pKviYbAo6Ze24h/Slrc6rNB Ww== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2gu5x181vm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Mar 2018 16:45:00 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2KGixAv013977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Mar 2018 16:45:00 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2KGiw7I011644; Tue, 20 Mar 2018 16:44:58 GMT Received: from [10.0.2.223] (/213.57.127.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Mar 2018 09:44:58 -0700 Message-ID: <5AB13A86.9010607@ORACLE.COM> Date: Tue, 20 Mar 2018 18:44:54 +0200 From: Liran Alon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eric W. Biederman" CC: shmulik.ladkani@gmail.com, netdev@vger.kernel.org, mrv@mojatatu.com, daniel@iogearbox.net, davem@davemloft.net, linux-kernel@vger.kernel.org, yuval.shaia@ORACLE.COM, idan.brown@ORACLE.COM Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns References: <0d84d286-9965-45cb-93c8-379ca1b2441e@default> <87tvta67gl.fsf@xmission.com> In-Reply-To: <87tvta67gl.fsf@xmission.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8838 signatures=668695 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-1803200127 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/03/18 18:24, ebiederm@xmission.com wrote: > > I don't believe the current behavior is a bug. > > I looked through the history. Basically skb_scrub_packet > started out as the scrubbing needed for crossing network > namespaces. > > Then tunnels which needed 90% of the functionality started > calling it, with the xnet flag added. Because the tunnels > needed to preserve their historic behavior. > > Then dev_forward_skb started calling skb_scrub_packet. > > A veth pair is supposed to give the same behavior as a cross-over > cable plugged into two local nics. A cross over cable won't > preserve things like the skb mark. So I don't see why anyone would > expect a veth pair to preserve the mark. I disagree with this argument. I think that a skb crossing netns is what simulates a real packet crossing physical computers. Following your argument, why would skb->mark should be preserved when crossing netdevs on same netns via routing? But this does today preserve skb->mark. Therefore, I do think that skb->mark should conceptually only be scrubbed when crossing netns. Regardless of the netdev used to cross it. > > Right now I don't see the point of handling packets that don't cross > network namespace boundaries specially, other than to preserve backwards > compatibility. > > Eric >