Received: by 10.213.65.68 with SMTP id h4csp533959imn; Tue, 20 Mar 2018 09:02:10 -0700 (PDT) X-Google-Smtp-Source: AG47ELsFK5SmO5uYXgofdF9cwEq7bjvV8tRKe6F5tklDUsGoC1ItdmgctBgmr4bmJrJ6TNN5rita X-Received: by 10.101.80.3 with SMTP id f3mr12652223pgo.242.1521561729990; Tue, 20 Mar 2018 09:02:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521561729; cv=none; d=google.com; s=arc-20160816; b=uH48NCbQyp0XdyWL3FoUUQGivzSkErP7DAbEGop5t3h60zhCAx2qWlsR6HylQ64W+T cE0N2vfpbWsBIb0KHPgwqnG2U3zwgdeHDo9CtIeBZX6yqtuhDc4Tf//cj+hUvoIaPreA EiP37eYNzpHo3tuzwZZn4y2SfOlHGUtXaeqwGeMxLvmRWVTKPbZG5mQlkV8DS1BTnXHO LTvIN/JAoER3EnPKxQvMViuBPwJMC+IULXF8yIqNrVp18VC6rf+uByUMduQeUkJv9EGB lXFxsdcwSlbJZWf6kkvOATf13c8wBQeRzLW9U9PYhuD86tOD9KhE7btzVS7ecBekHnhr rAVw== 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:from:subject:cc:to:message-id:date :arc-authentication-results; bh=zYYTQYsnuVZfIkIR4q0pQ8E1FQTpxMEgXc3jYNg0Pck=; b=R5mjPuzLPbyditVuuUZIh+0ztcFZtv2S4JCfLiyH/pkLCkJCPmbxsnqbkoGR3bMfx0 /NGh8U2FhQaoBRAZP1Iv5s+6F4f5THTbuJPwFFmVKJJjKDMgPl0Oznu2RQOyNXu6045h GEMxIrU6tpTe8JR9DWEjgLtlS+C+nN0r3E0TZIoNlhnUWpi2xLcsU4zPp4vUm7cUAwOr D7QGegmk8zKaHbSm/yhzprfw+FOlHh+Jujb7WhughNssWFmWGgVJDow222zT9SFT0Gaw S1ZIzTtkJnPAjIIwMbO7MFLmoXn2I6sa5eRqfgp1Fsspz4vs7Nsx2qNMw+qsSyDAIodG l7Bg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f12-v6si2045647pln.211.2018.03.20.09.01.54; Tue, 20 Mar 2018 09:02:09 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751628AbeCTQAn (ORCPT + 99 others); Tue, 20 Mar 2018 12:00:43 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:56234 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751422AbeCTQAk (ORCPT ); Tue, 20 Mar 2018 12:00:40 -0400 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id D5B7510174829; Tue, 20 Mar 2018 09:00:39 -0700 (PDT) Date: Tue, 20 Mar 2018 12:00:36 -0400 (EDT) Message-Id: <20180320.120036.1999626754164343704.davem@davemloft.net> To: LIRAN.ALON@ORACLE.COM Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, idan.brown@ORACLE.COM, yuval.shaia@ORACLE.COM Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns From: David Miller In-Reply-To: <5AB12A0E.2060704@ORACLE.COM> References: <1520953642-8145-1-git-send-email-liran.alon@oracle.com> <20180320.104759.796804827689233281.davem@davemloft.net> <5AB12A0E.2060704@ORACLE.COM> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 20 Mar 2018 09:00:40 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Liran Alon Date: Tue, 20 Mar 2018 17:34:38 +0200 > I personally don't understand why we should maintain > backwards-comparability to this behaviour. The reason is because not breaking things is a cornerstone of Linux kernel development. > This feature is not documented to user-mode and I don't see why it > is legit for the user to rely on it. Whether it is documented or not is irrelevant. A lot of our interfaces and behaviors are not documented or poorly documented at best. > In addition, even if we do want to maintain backwards-comparability to > this behaviour, I think it is enough to have an opt-in flag in > /proc/sys/net/core/ that when set to 1 will activate the fix in > dev_forward_skb() provided by this patch. That would also be a very > simple change to the patch provided here. Making it opt-in makes it more palatable, that's for sure.