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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.