From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Benc Subject: Re: [PATCH net-next v2 3/4] net: check tunnel option type in tunnel flags Date: Thu, 28 Jun 2018 09:42:06 +0200 Message-ID: <20180628094206.62b6d8e2@redhat.com> References: <20180627043937.25431-1-jakub.kicinski@netronome.com> <20180627043937.25431-4-jakub.kicinski@netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jakub Kicinski , davem@davemloft.net, Roopa Prabhu , jiri@resnulli.us, jhs@mojatatu.com, xiyou.wangcong@gmail.com, oss-drivers@netronome.com, netdev@vger.kernel.org, Pieter Jansen van Vuuren To: Daniel Borkmann Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:38366 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S965231AbeF1HmP (ORCPT ); Thu, 28 Jun 2018 03:42:15 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 27 Jun 2018 11:49:49 +0200, Daniel Borkmann wrote: > Looks good to me, and yes in BPF case a mask like TUNNEL_OPTIONS_PRESENT is > right approach since this is opaque info and solely defined by the BPF prog > that is using the generic helper. Wouldn't it make sense to introduce some safeguards here (in a backward compatible way, of course)? It's easy to mistakenly set data for a different tunnel type in a BPF program and then be surprised by the result. It might help users if such usage was detected by the kernel, one way or another. I'm thinking about something like the BPF program voluntarily specifying the type of the data; if not specified, the wildcard would be used as it is now. Jiri