Received: by 10.213.65.68 with SMTP id h4csp559103imn; Tue, 20 Mar 2018 09:35:23 -0700 (PDT) X-Google-Smtp-Source: AG47ELsmQ9Q7NEwwxpbZ4UrvlM/pMXwvQ5sEKB/FWNDGJFHr9Xafh2mrIfCd1rrzn18+JihUPbrp X-Received: by 2002:a17:902:12e:: with SMTP id 43-v6mr16873499plb.77.1521563723809; Tue, 20 Mar 2018 09:35:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521563723; cv=none; d=google.com; s=arc-20160816; b=ZHzFkt1/+Oev8lwYU2B9mNMyxPlbVE41txST/t6M64ybxCQO3ME4q857380Z2CG7/E JCmyoZgEXAoAY75vE8CQ40YxHcFyhRGNREZdJMT9Lwvl7j+uGiY+r2MZaj8barsNg6BH diNKkyrLP0poY9pqQOfjMQCEgXkF91woWx1M4xe82KAAdv6oNmvou4ESX4BffzhaqcgK 4H2RWEH41ng3dlEoIf8jKtAItJ6QIJgrxVJfltw5V9oYMSv5CzDan7RO+P1Uxllbfrcm L955KsqkLc9HXwfjOMVMtvmFh74379TWowV86cOGlRAYN+wNt9W8YAJ6VVy/VwK7QrVP GMAQ== 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=TCn2US4TToR7b835oAk10Vgd1457hJ0rtrE/xjC7NfM=; b=oPPM8P40GX1qE6gpBkL+34HTIWJothCV7htg7GL+jjmoPimcGBJT0jxtKTa/GpvklH rzwW8foE2v4n3ESBmienjofo0M5CzBwCNlQ3bruSGjavLbiK9SQAP8jgq66YWsLvqYGz gc15kbG/nTRocag9ofIDfLxLbyRbcBRucHC7dKQb6bsRLEL5/GJq2S9XE/+fqdDMewpe ih6z/G5MdHAg/YhBAIhnm1c3oOhqylklnoUXh62S06E2OrfXe8SEJOig7UO9LwwG9hq/ MLbeZauFbGuB/rHPNk2/RqKWCLdxi+BzsWAYl4GX5IxCV8ITn5V512iYupmb/x2+4YQm J8RA== 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 a8si1349730pgd.749.2018.03.20.09.35.09; Tue, 20 Mar 2018 09:35:23 -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 S1751798AbeCTQeF (ORCPT + 99 others); Tue, 20 Mar 2018 12:34:05 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:56830 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751682AbeCTQeD (ORCPT ); Tue, 20 Mar 2018 12:34:03 -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 D1D22144C8154; Tue, 20 Mar 2018 09:34:02 -0700 (PDT) Date: Tue, 20 Mar 2018 12:34:01 -0400 (EDT) Message-Id: <20180320.123401.2138083793709750726.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: <5AB132C5.5010806@ORACLE.COM> References: <5AB12A0E.2060704@ORACLE.COM> <20180320.120036.1999626754164343704.davem@davemloft.net> <5AB132C5.5010806@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:34:03 -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 18:11:49 +0200 > 1. Do we want to make a flag for every bug that is user-space visible? > I think there is place for consideration on a per-case basis. I still > don't see how a user can utilize this behaviour. He is basically > loosing information (skb->mark) without this patch. And maybe people trying to work in this situation have added code to get the mark set some other way, or to validate that it is in fact zero after passing through, which we would break with this change. If it's set to zero now, it's reasonable to expect it to be zero. By changing it to non-zero, different rules and routes will match and this for sure has potential to break things.