All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "kafai@fb.com" <kafai@fb.com>,
	"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 21:01:21 +0200	[thread overview]
Message-ID: <20190610210121.5d543bb0@redhat.com> (raw)
In-Reply-To: <876287da6e45876a9874782a00eea0b6cb8a9aa0.camel@fi.rohmeurope.com>

Hi Matti,

On Mon, 10 Jun 2019 05:56:03 +0000
"Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com> wrote:

> 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!

I was looking for lost UDP jokes. :)

> 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 :)

Well, yes, it wouldn't have become more complicated. The difference
today is that, with NLM_F_DUMP_FILTERED codifying this, we could safely
and simply skip userspace filtering with just two lines, something like:

	if (n->nlmsg_flags & RTM_F_DUMP_FILTERED)
		return 1;

in filter_nlmsg().

> 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.

Indeed, we'll have to take care of both. It's on my to do list now, I
should get to it soon.

Right now my priority is to fix the fact that, at least with iproute2,
flushing IPv6 routed caches is simply not possible anymore. This looks
like a serious breakage to me.

-- 
Stefano

  reply	other threads:[~2019-06-10 19:01 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
2019-06-10 19:01                   ` Stefano Brivio [this message]
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=20190610210121.5d543bb0@redhat.com \
    --to=sbrivio@redhat.com \
    --cc=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=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.