On Mon, 10 Jun 2019 19:42:41 +
Martin Lau wrote:
> On Sat, Jun 08, 2019 at 05:47:07PM +0200, Stefano Brivio wrote:
> > On Sat, 8 Jun 2019 17:02:06 +0200
> > Stefano Brivio wrote:
> >
> > > On Sat, 8 Jun 2019 07:19:23 +
> > > Martin Lau wrote:
> > >
> > > > On Sat, Jun 08, 2019 at
On Sat, Jun 08, 2019 at 05:47:07PM +0200, Stefano Brivio wrote:
> On Sat, 8 Jun 2019 17:02:06 +0200
> Stefano Brivio wrote:
>
> > On Sat, 8 Jun 2019 07:19:23 +
> > Martin Lau wrote:
> >
> > > On Sat, Jun 08, 2019 at 07:59:11AM +0200, Stefano Brivio wrote:
> > > > I also agree it makes mor
Hi Matti,
On Mon, 10 Jun 2019 05:56:03 +
"Vaittinen, Matti" 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. :)
>
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) ac
On Sat, 8 Jun 2019 17:02:06 +0200
Stefano Brivio wrote:
> On Sat, 8 Jun 2019 07:19:23 +
> Martin Lau wrote:
>
> > On Sat, Jun 08, 2019 at 07:59:11AM +0200, Stefano Brivio wrote:
> > > I also agree it makes more sense to filter routes this way.
> > >
> > > But it wasn't like this before 2
On Sat, 8 Jun 2019 07:19:23 +
Martin Lau wrote:
> On Sat, Jun 08, 2019 at 07:59:11AM +0200, Stefano Brivio wrote:
> > I also agree it makes more sense to filter routes this way.
> >
> > But it wasn't like this before 2b760fcf5cfb, so this smells like
> > breaking userspace expectations, even
On Sat, Jun 08, 2019 at 07:59:11AM +0200, Stefano Brivio wrote:
> On Sat, 8 Jun 2019 05:40:06 +
> Martin Lau wrote:
>
> > On Thu, Jun 06, 2019 at 04:47:00PM -0600, David Ahern wrote:
> > > On 6/6/19 3:18 PM, Stefano Brivio wrote:
> > > > On Thu, 6 Jun 2019 14:57:33 -0600
> > > > David Ahern
On Sat, 8 Jun 2019 05:40:06 +
Martin Lau wrote:
> On Thu, Jun 06, 2019 at 04:47:00PM -0600, David Ahern wrote:
> > On 6/6/19 3:18 PM, Stefano Brivio wrote:
> > > On Thu, 6 Jun 2019 14:57:33 -0600
> > > David Ahern wrote:
> > >
> > >>> This will cause a non-trivial conflict with commit c
On Thu, Jun 06, 2019 at 04:47:00PM -0600, David Ahern wrote:
> On 6/6/19 3:18 PM, Stefano Brivio wrote:
> > On Thu, 6 Jun 2019 14:57:33 -0600
> > David Ahern wrote:
> >
> >>> This will cause a non-trivial conflict with commit cc5c073a693f
> >>> ("ipv6: Move exception bucket to fib6_nh") on net-ne
On Thu, 6 Jun 2019 16:48:51 -0600
David Ahern wrote:
> On 6/6/19 4:37 PM, Martin Lau wrote:
> >> I don't think that can happen in practice, or at least I haven't found a
> >> way to create enough valid exceptions for the same node.
> > That I am not sure. It is not unusual to have many pmtu ex
On Fri, Jun 07, 2019 at 12:58:52AM +0200, Stefano Brivio wrote:
> On Thu, 6 Jun 2019 22:37:11 +
> Martin Lau wrote:
>
> > On Fri, Jun 07, 2019 at 12:17:47AM +0200, Stefano Brivio wrote:
> > > On Thu, 6 Jun 2019 21:44:58 +
> > > Martin Lau wrote:
> > >
> > > > > + if (!(filter->fla
On 6/6/19 4:58 PM, Stefano Brivio wrote:
>>> This also means that to avoid sending duplicates in the case where at
>>> least one rt6_fill_node() call goes through and one fails, we would
>>> need to track the last bucket and entry sent, or, alternatively, to
>>> make sure we can fit the whole node
On Fri, 7 Jun 2019 00:58:52 +0200
Stefano Brivio wrote:
> On Thu, 6 Jun 2019 22:37:11 +
> Martin Lau wrote:
>
> > On Fri, Jun 07, 2019 at 12:17:47AM +0200, Stefano Brivio wrote:
> > > On Thu, 6 Jun 2019 21:44:58 +
> > > Martin Lau wrote:
> > >
> > > > > + if (!(filter->flags
On Thu, 6 Jun 2019 16:47:00 -0600
David Ahern wrote:
> On 6/6/19 3:18 PM, Stefano Brivio wrote:
> > On Thu, 6 Jun 2019 14:57:33 -0600
> > David Ahern wrote:
> >
> >>> This will cause a non-trivial conflict with commit cc5c073a693f
> >>> ("ipv6: Move exception bucket to fib6_nh") on net-next.
On Thu, 6 Jun 2019 22:37:11 +
Martin Lau wrote:
> On Fri, Jun 07, 2019 at 12:17:47AM +0200, Stefano Brivio wrote:
> > On Thu, 6 Jun 2019 21:44:58 +
> > Martin Lau wrote:
> >
> > > > + if (!(filter->flags & RTM_F_CLONED)) {
> > > > + err = rt6_fill_node(net, arg->sk
On 6/6/19 4:37 PM, Martin Lau wrote:
>> I don't think that can happen in practice, or at least I haven't found a
>> way to create enough valid exceptions for the same node.
> That I am not sure. It is not unusual to have many pmtu exceptions in
> a gateway node.
>
yes.
Stefano: you could genera
On 6/6/19 3:18 PM, Stefano Brivio wrote:
> On Thu, 6 Jun 2019 14:57:33 -0600
> David Ahern wrote:
>
>>> This will cause a non-trivial conflict with commit cc5c073a693f
>>> ("ipv6: Move exception bucket to fib6_nh") on net-next. I can submit
>>> an equivalent patch against net-next, if it helps.
>
On Fri, Jun 07, 2019 at 12:17:47AM +0200, Stefano Brivio wrote:
> On Thu, 6 Jun 2019 21:44:58 +
> Martin Lau wrote:
>
> > > + if (!(filter->flags & RTM_F_CLONED)) {
> > > + err = rt6_fill_node(net, arg->skb, rt, NULL, NULL, NULL, 0,
> > > + RTM_NEWROUTE,
>
On Thu, 6 Jun 2019 21:44:58 +
Martin Lau wrote:
> > + if (!(filter->flags & RTM_F_CLONED)) {
> > + err = rt6_fill_node(net, arg->skb, rt, NULL, NULL, NULL, 0,
> > + RTM_NEWROUTE,
> > + NETLINK_CB(arg->cb->skb).portid,
> >
On Thu, Jun 06, 2019 at 10:13:41PM +0200, Stefano Brivio wrote:
> Since commit 2b760fcf5cfb ("ipv6: hook up exception table to store dst
> cache"), route exceptions reside in a separate hash table, and won't be
> found by walking the FIB, so they won't be dumped to userspace on a
> RTM_GETROUTE mes
On Thu, 6 Jun 2019 14:57:33 -0600
David Ahern wrote:
> > This will cause a non-trivial conflict with commit cc5c073a693f
> > ("ipv6: Move exception bucket to fib6_nh") on net-next. I can submit
> > an equivalent patch against net-next, if it helps.
> >
>
> Thanks for doing this. It is on my t
On 6/6/19 2:13 PM, Stefano Brivio wrote:
> Since commit 2b760fcf5cfb ("ipv6: hook up exception table to store dst
> cache"), route exceptions reside in a separate hash table, and won't be
> found by walking the FIB, so they won't be dumped to userspace on a
> RTM_GETROUTE message.
>
> This causes
Since commit 2b760fcf5cfb ("ipv6: hook up exception table to store dst
cache"), route exceptions reside in a separate hash table, and won't be
found by walking the FIB, so they won't be dumped to userspace on a
RTM_GETROUTE message.
This causes 'ip -6 route list cache' and 'ip -6 route flush cache
23 matches
Mail list logo
