From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net v2] fib_semantics: Don't match route with mismatching tclassid Date: Fri, 16 Feb 2018 15:21:26 -0500 (EST) Message-ID: <20180216.152126.89359602115635995.davem@davemloft.net> References: <20180215084603.64905-1-sbrivio@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dsahern@gmail.com, kuznet@ms2.inr.ac.ru, tgraf@suug.ch, jishi@redhat.com, netdev@vger.kernel.org To: sbrivio@redhat.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:58450 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750713AbeBPUVb (ORCPT ); Fri, 16 Feb 2018 15:21:31 -0500 In-Reply-To: <20180215084603.64905-1-sbrivio@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Stefano Brivio Date: Thu, 15 Feb 2018 09:46:03 +0100 > In fib_nh_match(), if output interface or gateway are passed in > the FIB configuration, we don't have to check next hops of > multipath routes to conclude whether we have a match or not. > > However, we might still have routes with different realms > matching the same output interface and gateway configuration, > and this needs to cause the match to fail. Otherwise the first > route inserted in the FIB will match, regardless of the realms: > > # ip route add 1.1.1.1 dev eth0 table 1234 realms 1/2 > # ip route append 1.1.1.1 dev eth0 table 1234 realms 3/4 > # ip route list table 1234 > 1.1.1.1 dev eth0 scope link realms 1/2 > 1.1.1.1 dev eth0 scope link realms 3/4 > # ip route del 1.1.1.1 dev ens3 table 1234 realms 3/4 > # ip route list table 1234 > 1.1.1.1 dev ens3 scope link realms 3/4 > > whereas route with realms 3/4 should have been deleted instead. > > Explicitly check for fc_flow passed in the FIB configuration > (this comes from RTA_FLOW extracted by rtm_to_fib_config()) and > fail matching if it differs from nh_tclassid. > > The handling of RTA_FLOW for multipath routes later in > fib_nh_match() is still needed, as we can have multiple RTA_FLOW > attributes that need to be matched against the tclassid of each > next hop. > > v2: Check that fc_flow is set before discarding the match, so > that the user can still select the first matching rule by > not specifying any realm, as suggested by David Ahern. > > Reported-by: Jianlin Shi > Signed-off-by: Stefano Brivio Applied and queued up for -stable, thanks.