From: Shmulik Ladkani <shmulik@nsof.io>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, mateusz.bajorski@nokia.com,
dsa@cumulusnetworks.com, tgraf@suug.ch,
shmulik.ladkani@gmail.com
Subject: Re: [PATCH net] net: fib_rules: Fix fib_rules_ops->compare implementations to support exact match
Date: Sat, 7 Oct 2017 09:04:35 +0300 [thread overview]
Message-ID: <20171007090435.0a793acc@pixies> (raw)
Hi David,
On Tue, 03 Oct 2017 14:54:18 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> From: Shmulik Ladkani <shmulik@nsof.io>
> Date: Sat, 30 Sep 2017 11:59:09 +0300
>
> > This leads to inconsistencies, depending on order of operations, e.g.:
>
> I don't see any inconsistency. When you insert using NLM_F_EXCL the
> insertion fails if any existing rule matches or overlaps in any way
> with the keys in the new rule.
(Haven't seen any response to https://patchwork.ozlabs.org/patch/820186/
for a while.
The original description of the problem was vague.
Summarizing the arguments here)
The "matches or overlaps in any way" statement is incorrect for fib
rules; strict exact comparison of the addresses is performed,
see snip of fib4_rule_compare:
if (frh->src_len && (rule4->src_len != frh->src_len))
return 0;
...
if (frh->src_len && (rule4->src != nla_get_in_addr(tb[FRA_SRC])))
return 0;
(with the ONLY exception of src_len being zero, i.e. FRA_SRC not being
specified, where comparison is skipped, and compare result defaults to
true)
Therefore, one can successfully add various overlapping rules in any
arbitrary order:
ip ru a from 10.20.0.0/16 iif eth2 pref 22 table 22
ip ru a from 10.0.0.0/8 iif eth2 pref 22 table 22
ip ru a from 10.20.30.0/24 iif eth2 pref 22 table 22
ip ru a from 0.0.0.0/4 iif eth2 pref 22 table 22
ip ru a from 0.0.0.0/1 iif eth2 pref 22 table 22
ip ru a from 0.0.0.0/2 iif eth2 pref 22 table 22
One can also add various overlapping rules, after the 0.0.0.0/0 rule has
been initially inserted:
ip ru a from 0.0.0.0/0 iif eth2 pref 33 table 33
ip ru a from 10.0.0.0/8 iif eth2 pref 33 table 33
ip ru a from 0.0.0.0/4 iif eth2 pref 33 table 33
But one cannot add the 0.0.0.0/0 rule after other rules have been
inserted:
ip ru a from 10.20.30.0/24 iif eth2 pref 44 table 44
ip ru a from 10.0.0.0/8 iif eth2 pref 44 table 44
ip ru a from 0.0.0.0/0 iif eth2 pref 44 table 44
RTNETLINK answers: File exists
This behaviour is unexpected for the user program, as it needs to
"sort" its insertions if it has a 0.0.0.0/0 rule among the rules
it wishes to add.
The purpose of NLM_F_EXCL is for ensuring rule exclusiveness, as
explained in commit 153380ec4b9b; there's no overlap semantics in none
of the fib_rules_ops->compare implementations.
next reply other threads:[~2017-10-07 6:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-07 6:04 Shmulik Ladkani [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-09-30 8:59 [PATCH net] net: fib_rules: Fix fib_rules_ops->compare implementations to support exact match Shmulik Ladkani
2017-10-03 21:54 ` David Miller
2017-10-04 3:58 ` Eyal Birger
2017-10-04 4:40 ` David Ahern
2017-10-04 5:34 ` Shmulik Ladkani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171007090435.0a793acc@pixies \
--to=shmulik@nsof.io \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=mateusz.bajorski@nokia.com \
--cc=netdev@vger.kernel.org \
--cc=shmulik.ladkani@gmail.com \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).