From: Stefano Brivio <sbrivio@redhat.com>
To: David Ahern <dsahern@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Martin KaFai Lau <kafai@fb.com>, Jianlin Shi <jishi@redhat.com>,
Wei Wang <weiwan@google.com>, Eric Dumazet <edumazet@google.com>,
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net v4 1/8] ipv4/fib_frontend: Rename ip_valid_fib_dump_req, provide non-strict version
Date: Mon, 17 Jun 2019 20:28:30 +0200 [thread overview]
Message-ID: <20190617202830.3dd92d46@redhat.com> (raw)
In-Reply-To: <43a9b0c7-27b4-733c-d3f2-60ad894e8aeb@gmail.com>
On Mon, 17 Jun 2019 11:06:51 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 6/17/19 8:13 AM, Stefano Brivio wrote:
> >>
> >> With strict checking (5.0 and forward):
> >> - RTM_F_CLONED NOT set means dump only FIB entries
> >> - RTM_F_CLONED set means dump only exceptions
> >
> > Okay. Should we really ignore the RFC and NLM_F_MATCH though? If we add
> > field(s) to the filter, it comes almost for free, something like:
> >
> > if (nlh->nlmsg_flags & NLM_F_MATCH)
> > filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
> >
> > instead of:
> >
> > filter->dump_exceptions = rtm->rtm_flags & RTM_F_CLONED;
>
> This is where you keep losing me. iproute2 has always set NLM_F_MATCH on
> dump requests, so that flag can not be used as a discriminator here.
iproute2 yes, but some other users (I'm not aware of any so I have no
examples) might *very* vaguely follow the RFC and expect consistent
results. That was my only point here. Most likely just a theoretical
one.
> >
> >> Without strict checking (old iproute2 on any kernel):
> >> - dump all, userspace has to sort
> >>
> >> Kernel side this can be handled with new field, dump_exceptions, in the
> >> filter that defaults to true and then is reset in the strict path if the
> >> flag is not set.
> >
> > I guess we need to add two fields, we'll need a 'dump_routes' too.
> >
> > Otherwise, the dump functions can't distinguish between the three cases
> > ('no strict checking', 'strict checking and RTM_F_CLONED', 'strict
> > checking and no RTM_F_CLONED'). How would you do this with a single
> > additional field?
> >
>
> sure, separate fields are needed for the pre-strict mode use case.
Well, they are needed, in general. They both start as true, non-strict
mode doesn't clear them, strict mode clears one. That's how I would do
it.
> So, I take it we are converging on this:
>
> 1. non-strict mode, dump both (FIB entries and exceptions). Userspace
> has to filter. This is the legacy behavior you are trying to restore.
>
> 2. strict mode:
> a. dump only FIB entries if RTM_F_CLONED is not set
> b. dump only exception entries if RTM_F_CLONED is set
>
> Agreed?
Agreed in general, maybe let me know what you think about the
NLM_F_MATCH point above though.
--
Stefano
next prev parent reply other threads:[~2019-06-17 18:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-15 1:32 [PATCH net v4 0/8] Fix listing (IPv4, IPv6) and flushing (IPv6) of cached route exceptions Stefano Brivio
2019-06-15 1:32 ` [PATCH net v4 1/8] ipv4/fib_frontend: Rename ip_valid_fib_dump_req, provide non-strict version Stefano Brivio
2019-06-15 2:54 ` David Ahern
2019-06-15 3:13 ` Stefano Brivio
2019-06-15 3:16 ` David Ahern
2019-06-15 3:27 ` Stefano Brivio
2019-06-16 20:04 ` Stefano Brivio
2019-06-17 13:38 ` David Ahern
2019-06-17 14:13 ` Stefano Brivio
2019-06-17 17:06 ` David Ahern
2019-06-17 18:28 ` Stefano Brivio [this message]
2019-06-17 13:18 ` David Ahern
2019-06-15 1:32 ` [PATCH net v4 2/8] ipv4: Honour NLM_F_MATCH, make semantics of NETLINK_GET_STRICT_CHK consistent Stefano Brivio
2019-06-15 3:13 ` David Ahern
2019-06-15 3:23 ` Stefano Brivio
2019-06-17 13:29 ` David Ahern
2019-06-15 1:32 ` [PATCH net v4 3/8] ipv4/fib_frontend: Allow RTM_F_CLONED flag to be used for filtering Stefano Brivio
2019-06-15 1:32 ` [PATCH 4/8] ipv4: Dump routed caches if requested Stefano Brivio
2019-06-15 1:32 ` [PATCH 5/8] Revert "net/ipv6: Bail early if user only wants cloned entries" Stefano Brivio
2019-06-15 1:32 ` [PATCH 6/8] ipv6: Honour NLM_F_MATCH, make semantics of NETLINK_GET_STRICT_CHK consistent Stefano Brivio
2019-06-15 1:32 ` [PATCH 7/8] ipv6: Dump route exceptions too in rt6_dump_route() Stefano Brivio
2019-06-15 1:32 ` [PATCH 8/8] ip6_fib: Don't discard nodes with valid routing information in fib6_locate_1() Stefano Brivio
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=20190617202830.3dd92d46@redhat.com \
--to=sbrivio@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=jishi@redhat.com \
--cc=kafai@fb.com \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=netdev@vger.kernel.org \
--cc=weiwan@google.com \
/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.