netdev - Re: [PATCH 0/4] Fix routing metrics

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: <20120206.152916.224032109057159733.davem@davemloft.net>
Date:	Mon, 06 Feb 2012 15:29:16 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	steffen.klassert@...unet.com
Cc:	timo.teras@....fi, netdev@...r.kernel.org
Subject: Re: [PATCH 0/4] Fix routing metrics

From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Thu, 2 Feb 2012 11:11:41 +0100

> At the moment we initialize the routing metrics with the, on the inetpeer
> cached values in rt_init_metrics(). So if we have the metrics cached on the
> inetpeer, we ignore the user configured fib_metrics. This leads to the fact 
> that we can't configure the mtu, hoplimit etc. if we have learned metrics 
> cached. This patchset adds a possibility to invalidate and exchange the
> cached inetpeer metrics. In detail it does:
> 
> 1. Allocate the inetpeer metrics dynamically and add a reference
> to the inetpeer.
> 
> 2. Remove the direct reference of the inetpeer metrics from
> dst->_metrics and access the metrics via the inetpeer reference
> of the route. This makes it possible to exchange the inetpeer
> metrics if they get invalidated.
> 
> 3. Protect the inetpeer metrics with rcu.
> 
> 4. Add a peer_genid to invalidate the metrics. When the peer_genid
> is incremeted we allocate new metrics and exchange the metrics
> pointer of the inetpeer.
> 
> For the case that such a approach is acceptable, I have another patch
> to unify peer_genid and redirect_genid.

Thinking about this, it seems overkill to check this on every metric
access.

You have an opportunity to validate metrics when the peer is bound to
the route.

This is because any change to the FIB metrics, is in turn a change
to the FIB, which therefore invalidates the entire routing cache.

So you can be sure that a new route cache entry will be created, and
at that creation time you can ensure that we'll respect the updated
FIB metrics if encessary.
--
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