Received: by 10.213.65.68 with SMTP id h4csp1716528imn; Thu, 15 Mar 2018 07:37:32 -0700 (PDT) X-Google-Smtp-Source: AG47ELvQX7erV+R+oKXQ83po7wfTkus2UutzyRcymNp/8n4Qngex1XVrch12DGOk7d5KQI1e6rPX X-Received: by 10.101.76.207 with SMTP id n15mr1105021pgt.313.1521124652156; Thu, 15 Mar 2018 07:37:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521124652; cv=none; d=google.com; s=arc-20160816; b=rkqypWfv/IWE6BPFRuLpK8y/VPGiWPGOfkBTG/H7ub3iN+RHBiVvonltCDdc+x5Zy7 iYKruF4R5FDOSOE4TOAJlH9ZjX+3CZTVQlKV1UzBsXuOyuDGfGC00ZF1Xhev8mQmhi0D vj1gcaNM2EUH2KoDDQEs+aHSEYRE2UZOP0iA5Ljoz6szXGvCyh4ajNtlXTG17YfEWFC2 ipaYchBufAkxgsdwZduUg/LTRUeg0sZjRe763vjfvs+ODoXQ/5Qr4/brCaMi7GBX7K6A DkyWAhB7iKDVbzEznWsg5kmeLQPaGupPu4rEf/2T8jZS1stCZEj3T2i2riHttTj1d0X/ fvoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=s+Nd6YwcvrkoNZ4kUbvM5fkgXg4HUzpVPPuqaKYKIxI=; b=eHTHQPM3Xw1hZcaBuG7dbgcmPMxdjV6dfFY0Xo/JKAcXdoH1OunKIvhDEfgSoUj0kL qA6cTqcpzRxxs1x13D6503VkgL7xBAX9JCgsyBKWkU5YUL49NY6svYPAXVyuiF19e0t0 N1l9GkFe5hTC3NVhUzYKo105GV1TcVNapr/O12jEMm8bH0QCRbAmRov9AxBrUoC3x5ZJ IvB8Y4XVaIFZ8ldfNE7+JxjmEejXFsjKDV8K3k78A+vjnhtXNMTHEReF5SBepd+4VI8G cQ6o1na1vNbwkKmuLd8aGBdeFpdZXoDGHc7HRVxwrAXs+UwrpjPi6eqwAWGY7bdlJLYg Ibjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mojatatu-com.20150623.gappssmtp.com header.s=20150623 header.b=xhPPD8Jv; 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 n1si3553437pgc.527.2018.03.15.07.37.09; Thu, 15 Mar 2018 07:37:32 -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=@mojatatu-com.20150623.gappssmtp.com header.s=20150623 header.b=xhPPD8Jv; 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 S1752573AbeCOOgA (ORCPT + 99 others); Thu, 15 Mar 2018 10:36:00 -0400 Received: from mail-it0-f50.google.com ([209.85.214.50]:52932 "EHLO mail-it0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752463AbeCOOfo (ORCPT ); Thu, 15 Mar 2018 10:35:44 -0400 Received: by mail-it0-f50.google.com with SMTP id k135-v6so9366672ite.2 for ; Thu, 15 Mar 2018 07:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=s+Nd6YwcvrkoNZ4kUbvM5fkgXg4HUzpVPPuqaKYKIxI=; b=xhPPD8Jv25BqSs/vB1kHF7/X6rwwWT7+k2Mn+uoewPoKDJFg4pZt3mSEPFgkXV/8XF uo8kHHSQI+a7IGzbvYQ283dlxR29bQPF9VfylajvgdGu0PsTle8o5xFD+Ay26QgjipXv tSaDN896Ub96HI6bcVMpU3jaI6HUC1+5N69ZHxb3N7GLv/Reeg29O4tnf1U1IwsVJmjo b+CrdOAvK9G7DKzaQ2cMSPSKGeblS3H8lxqv19qeZm22EJPn3D9WH16hwm9tBOT4/7// 3+tBFv05XoJR41b2k46DaPJQ4E8DmhTiV/WLDYozDjBsHSJYOxXu0305cMXj58NYMnyl s11w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=s+Nd6YwcvrkoNZ4kUbvM5fkgXg4HUzpVPPuqaKYKIxI=; b=e73Y1RNdHR2LqafqTOcWyZ2EeRRiLWiKPMWcM57aoNxKJqHSV6YN+QKwqUW6sqAZsM WXsWC8AjhrTaILBjVogwcHa0H92NIwJDzVzur4l5PUSOCUOTAl94F4VGm+IQ4GPco9JS WrANlIrTH6soV8oaQVAm/WrmjXIC2nZlI50E7t4uqD2V2KOKJMoUfxUVFB9tb/2gc7jz 46+70Ti4yyNhb1tF86Erz+uvG9F5vzfGsSt9wvZjCma9CTDAIWV1DRult81uopzPEzp9 +1BjLHTkUi305dfjinQCoUoc42qfKBh+sF5c2Ls29vSZdOep3xXGOpmNzziTpCwNzrIE F6vg== X-Gm-Message-State: AElRT7EbsLIAkobDoXN3nXSDja+5cQ4vzwSA+oaFUSEMwzTTF8OUb1SD /NIjqIuss769lSrAleWts95vog== X-Received: by 2002:a24:d8:: with SMTP id 207-v6mr6383276ita.3.1521124543708; Thu, 15 Mar 2018 07:35:43 -0700 (PDT) Received: from sevai ([64.26.149.125]) by smtp.gmail.com with ESMTPSA id f191sm3138980ite.4.2018.03.15.07.35.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 07:35:43 -0700 (PDT) From: Roman Mashak To: Liran Alon Cc: , , , , , , Subject: Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns References: Date: Thu, 15 Mar 2018 10:35:42 -0400 In-Reply-To: (Liran Alon's message of "Thu, 15 Mar 2018 05:23:41 -0700 (PDT)") Message-ID: <85woydh0e9.fsf@mojatatu.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Liran Alon writes: [...] >> Overall I think it might be nice to not need scrubbing skb in such >> cases, >> although my concern would be that this has potential to break >> existing >> setups when they would expect mark being zero on other veth peer in >> any >> case since it's the behavior for a long time already. The safer >> option >> would be to have some sort of explicit opt-in e.g. on link creation to >> let >> the skb->mark pass through unscrubbed. This would definitely be a >> useful >> option e.g. when mark is set in the netns facing veth via >> clsact/egress >> on xmit and when the container is unprivileged anyway. >> >> Thanks, >> Daniel > > I see your point in regards to backwards comparability. > However, not scrubbing skb when it cross netns via some kernel functions compared to > others is basically a bug which could easily break with a little bit of more refactoring. > Therefore, it seems a bit weird to me to from now on, we will force > every user on link creation to consider that once there was a bug leading > to this weird behavior on specific netdevs. > Thus, I suggest to maybe control this via a global /proc/sys/net file instead. One valid use case could be preserving a source namespace nsid in skb->mark when a packet crosses netns.