From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns Date: Tue, 20 Mar 2018 11:24:26 -0500 Message-ID: <87tvta67gl.fsf@xmission.com> References: <0d84d286-9965-45cb-93c8-379ca1b2441e@default> Mime-Version: 1.0 Content-Type: text/plain Cc: , , , , , , , To: Liran Alon Return-path: In-Reply-To: <0d84d286-9965-45cb-93c8-379ca1b2441e@default> (Liran Alon's message of "Thu, 15 Mar 2018 10:14:01 -0700 (PDT)") Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Liran Alon writes: > ----- shmulik.ladkani@gmail.com wrote: > >> On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon >> wrote: >> > ----- shmulik.ladkani@gmail.com wrote: >> > >> > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon >> > > wrote: >> > > > >> > > > I still think that default behavior should be to zero skb->mark >> only >> > > when skb >> > > > cross netdevs in different netns. >> > > >> > > But the previous default was scrub the mark in *both* xnet and >> > > non-xnet >> > > situations. >> > > >> > > Therefore, there might be users which RELY on this (strange) >> default >> > > behavior in their same-netns-veth-pair setups. >> > > Meaning, changing the default behavior might break their apps >> relying >> > > on >> > > the former default behavior. >> > > >> > > This is why the "disable mark scrubbing in non-xnet case" should >> be >> > > opt-in. >> > >> > We think the same. >> > The only difference is that I think this for now should be >> controllable >> > by a global /proc/sys/net/core file instead of giving a flexible >> per-netdev >> > control. >> > Because that is a larger change that could be done later. >> >> A flags attribute to veth newlink is a very scoped change. >> User controls this per veth creation. >> This is way more neat than /proc/sys/net and provides the desired >> granular >> control. >> >> Also, scoping this to veth has the advantage of not affecting the many >> other >> dev_forward_skb callers. > > Agreed. But isn't this an issue also for the > many others (& future) callers of dev_forward_skb()? > This seems problematic to me. > > This will kinda leave a kernel interface with broken default behavior > for backwards comparability. > > A flag to netdev or /proc/sys/net/core to "fix" default behavior > will avoid this. 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. 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