[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a88182c7-10ee-0505-3b5b-bec852e24e97@gmail.com>
Date: Tue, 18 Jun 2019 08:51:01 -0600
From: David Ahern <dsahern@...il.com>
To: Stefano Brivio <sbrivio@...hat.com>,
David Miller <davem@...emloft.net>
Cc: Jianlin Shi <jishi@...hat.com>, Wei Wang <weiwan@...gle.com>,
Martin KaFai Lau <kafai@...com>,
Eric Dumazet <edumazet@...gle.com>,
Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
netdev@...r.kernel.org
Subject: Re: [PATCH net v5 0/6] Fix listing (IPv4, IPv6) and flushing (IPv6)
of cached route exceptions
On 6/18/19 7:20 AM, Stefano Brivio wrote:
> For IPv6 cached routes, the commands 'ip -6 route list cache' and
> 'ip -6 route flush cache' don't work at all after route exceptions have
> been moved to a separate hash table in commit 2b760fcf5cfb ("ipv6: hook
> up exception table to store dst cache").
>
> For IPv4 cached routes, the command 'ip route list cache' has also
> stopped working in kernel 3.5 after commit 4895c771c7f0 ("ipv4: Add FIB
> nexthop exceptions.") introduced storage for route exceptions as a
> separate entity.
>
> Fix this by allowing userspace to clearly request cached routes with
> the RTM_F_CLONED flag used as a filter (in conjuction with strict
> checking) and by retrieving and dumping cached routes if requested.
>
> If strict checking is not requested (iproute2 < 5.0.0), we don't have a
> way to consistently filter results on other selectors (e.g. on tables),
> so skip filtering entirely and dump both regular routes and exceptions.
>
> I'm submitting this for net as these changes fix rather relevant
> breakages. However, the scope might be a bit broad, and said breakages
> have been introduced 7 and 2 years ago, respectively, for IPv4 and IPv6.
> Let me know if I should rebase this on net-next instead.
>
> For IPv4, cache flushing uses a completely different mechanism, so it
> wasn't affected. Listing of exception routes (modified routes pre-3.5) was
> tested against these versions of kernel and iproute2:
>
Changing the dump code has been notoriously tricky to get right in one
go, no matter how much testing you have done. Given that I think this
should go to net-next first and once it proves ok there we can look at a
backport to stable trees.
Powered by blists - more mailing lists