lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111222102526.GT6348@secunet.com>
Date:	Thu, 22 Dec 2011 11:25:26 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
Cc:	timo.teras@....fi, netdev@...r.kernel.org
Subject: Re: linux-3.0.x regression with ipv4 routes having mtu

On Wed, Dec 21, 2011 at 03:56:15PM -0500, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@...unet.com>
> Date: Wed, 21 Dec 2011 09:56:16 +0100
> 
> > My decscription was a bit missleading, sorry. This seems to be not
> > even related to pmtu handling. It's just that we don't use the
> > user configured metrics on the fib entry if we find an inetpeer
> > with metrics that are not in INETPEER_METRICS_NEW state when we
> > initialize the routing metrics in rt_init_metrics(). I tried to add
> > a route with a hoplimit, this has also no effect if the metrics on
> > the inetpeer are not new.
> 
> Ok, so what you're saying is that we need a way to invalidate inetpeer
> entries, or at least invalidate their cached metrics and set
> INETPEER_METRICS_NEW once more.

Yes, we probaply need to invalidate whenever the fib changes.
We would have to invalidate at least the cached metrics and
all the pmtu related stuff we have on the inetpeer now.
Not sure if it is better to just invalidate some pieces
or the whole inetpeer entries.

Actually, I'm getting some doubts on the concept of caching
the metrics on the inetpeer. How should we handle the case when
we have multiple routes with different metrics to the same
destination? As it is, we can cache just one of them on the
inetpeer.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ