From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Subject: Re: [PATCH net-next v5 1/4] net/sched: user-space can't set unknown tcfa_action values Date: Tue, 31 Jul 2018 16:40:58 +0200 Message-ID: References: <951ad078ad4d5ee108abcd85189460aed7948634.1532934532.git.pabeni@redhat.com> <79b9d1a7-64ea-e385-1dcb-1f38955a01dd@mojatatu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Cong Wang , Jiri Pirko , Daniel Borkmann , Marcelo Ricardo Leitner , Eyal Birger , "David S. Miller" To: Jamal Hadi Salim , netdev@vger.kernel.org Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:35302 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732351AbeGaQVj (ORCPT ); Tue, 31 Jul 2018 12:21:39 -0400 In-Reply-To: <79b9d1a7-64ea-e385-1dcb-1f38955a01dd@mojatatu.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 2018-07-31 at 09:53 -0400, Jamal Hadi Salim wrote: > BTW, I asked this earlier and Jiri said it was addressed in patch 2. > I just looked again and i may be missing something basic: > Lets say tomorrow in a new kernel we add new TC_ACT_XXX that then gets > exposed to uapi - so user space tc is updated. > You then use the new tc specifying TC_ACT_XXX policy on kernel with your > changes. > If i read correctly because TC_ACT_XXX is out of bounds for current > kernel(which has your changes) you will fix it to be UNSPEC, no? You are right. If we choose to reject unknown opcodes, such user-space configuration will fail. What would happen before this patch is that configurations using such TC_ACT_XXXX value would be successful. This is why I proposed to keep the fixup. I initially thought the kernel behavior in the above scenario would match exactly TC_ACT_UNSPEC processing, but as you noted with the example in your previous email, TC_ACT_UNSPEC processing is actually a bit different. Cheers, Paolo