Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 29 Sep 2021 06:19:09 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc:     Toms Atteka <cpp.code.lv@gmail.com>, netdev@vger.kernel.org,
        pshelar@ovn.org, davem@davemloft.net, dev@openvswitch.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v6] net: openvswitch: IPv6: Add IPv6 extension
 header support
Message-ID: <20210929061909.59c94eff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
In-Reply-To: <d1e5b178-47f5-9791-73e9-0c1f805b0fca@6wind.com>
References: <20210928194727.1635106-1-cpp.code.lv@gmail.com>
        <20210928174853.06fe8e66@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
        <d1e5b178-47f5-9791-73e9-0c1f805b0fca@6wind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 29 Sep 2021 08:19:05 +0200 Nicolas Dichtel wrote:
> > /* Insert a kernel only KEY_ATTR */
> > #define OVS_KEY_ATTR_TUNNEL_INFO	__OVS_KEY_ATTR_MAX
> > #undef OVS_KEY_ATTR_MAX
> > #define OVS_KEY_ATTR_MAX		__OVS_KEY_ATTR_MAX  
> Following the other thread [1], this will break if a new app runs over an old
> kernel.

Good point.

> Why not simply expose this attribute to userspace and throw an error if a
> userspace app uses it?

Does it matter if it's exposed or not? Either way the parsing policy
for attrs coming from user space should have a reject for the value.
(I say that not having looked at the code, so maybe I shouldn't...)