netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "kafai@fb.com" <kafai@fb.com>, "sbrivio@redhat.com" <sbrivio@redhat.com>
Cc: "dsahern@gmail.com" <dsahern@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"weiwan@google.com" <weiwan@google.com>,
	"jishi@redhat.com" <jishi@redhat.com>,
	"edumazet@google.com" <edumazet@google.com>
Subject: Re: [PATCH net 1/2] ipv6: Dump route exceptions too in rt6_dump_route()
Date: Mon, 10 Jun 2019 05:56:03 +0000	[thread overview]
Message-ID: <876287da6e45876a9874782a00eea0b6cb8a9aa0.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20190608170206.4fa108f5@redhat.com>

Hi Dee Ho Peeps!

Wow Stefano, you seem to be quite a detective :) How on earth did you
match my new email to this sole netdev intrusion done back at the 2011
%) Impressive!

On Sat, 2019-06-08 at 17:02 +0200, Stefano Brivio wrote:

> 
> - retry adding NLM_F_MATCH (for net-next and iproute-next) according
>   to RFC 3549. Things changed a bit from 2011: we now have
>   NLM_F_DUMP_FILTERED, iproute2 already uses it (ip neigh) and we
>   wouldn't need to make iproute2 more complicated by handling old/new
>   kernel cases. So I think this would be reasonable now.
> 
I am pretty sure the iproute would not have become more complicated
back in 2011 even if we did push this change back then. iproute2 could
have chosen to stick with own userspace filtering - supporting the
NLM_F_MATCH flag back then would not have broken that. And if we did it
back then - there now probably was some other tools utilizing the
kernel filtering - and today the iproute2 could pretty safely drop the
user-space route filtering code and transition to do filtering already
in kernel. Well, that's a bit late to say today :)

But yes, this unfinished thing has indeed haunted me during some black
nights =) I would be delighted to see the proper NLM_F_MATCH support in
kernel.

What stopped me back in the 2011 was actually Dave's comment that even
if he could consider applying this change he would require it for IPv4
too. And that makes perfect sense. It was just too much for me back
then. I guess this has not changed - IPv6 and IPv4 should still handle
these flags in a same way.

Br,
	Matti Vaittinen

  parent reply	other threads:[~2019-06-10  5:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 20:13 [PATCH net 0/2] ipv6: Fix listing and flushing of cached route exceptions Stefano Brivio
2019-06-06 20:13 ` [PATCH net 1/2] ipv6: Dump route exceptions too in rt6_dump_route() Stefano Brivio
2019-06-06 20:57   ` David Ahern
2019-06-06 21:18     ` Stefano Brivio
2019-06-06 22:47       ` David Ahern
2019-06-06 23:07         ` Stefano Brivio
2019-06-08  5:40         ` Martin Lau
2019-06-08  5:59           ` Stefano Brivio
2019-06-08  7:19             ` Martin Lau
2019-06-08 15:02               ` Stefano Brivio
2019-06-08 15:47                 ` Stefano Brivio
2019-06-10 19:42                   ` Martin Lau
2019-06-10 21:01                     ` Stefano Brivio
2019-06-10  5:56                 ` Vaittinen, Matti [this message]
2019-06-10 19:01                   ` Stefano Brivio
2019-06-06 21:44   ` Martin Lau
2019-06-06 22:17     ` Stefano Brivio
2019-06-06 22:37       ` Martin Lau
2019-06-06 22:48         ` David Ahern
2019-06-07  1:54           ` Stefano Brivio
2019-06-06 22:58         ` Stefano Brivio
2019-06-06 23:15           ` Stefano Brivio
2019-06-06 23:19           ` David Ahern
2019-06-06 23:31           ` Martin Lau
2019-06-06 20:13 ` [PATCH net 2/2] 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=876287da6e45876a9874782a00eea0b6cb8a9aa0.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=jishi@redhat.com \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=sbrivio@redhat.com \
    --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 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).