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: <20120221.013623.263612018908941497.davem@davemloft.net>
Date:	Tue, 21 Feb 2012 01:36:23 -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: Tue, 21 Feb 2012 07:19:22 +0100

> On Fri, Feb 10, 2012 at 01:25:57PM -0500, David Miller wrote:
>> From: Steffen Klassert <steffen.klassert@...unet.com>
>> Date: Fri, 10 Feb 2012 09:44:25 +0100
>> 
>> > On Fri, Feb 10, 2012 at 03:12:11AM -0500, David Miller wrote:
>> >> 
>> >> So since this happens, you don't need to check the inetpeer at every
>> >> metric access.  The fact that all routing cache entries get recreated
>> >> will do it for you.
>> > 
>> > So if rt_init_metrics() is not the right place to check for genid
>> > changes, where would you suggest to do it?
>> 
>> It is the right place, and since it will happen there for every routing
>> cache entry we use after a flush, the inetpeer issues will be taken
>> care of by it.  Therefore you don't need to check anything at metrics
>> access time.
> 
> Ok, apparently I looked at the wrong place. The only checks at metrics
> access that might be superfluous are the inet_metrics_new() checks in
> ipv4_metrics() and ipv6_metrics(). If these are the checks you mean,
> I'd remove them and resend the patchset.

I'm saying you shouldn't need a metrics access callback nor the rest
of your patch at all.

Look, when routes change, the routing cache is flushed and the gen ID
is incremented.

Every single existing routing cache entry is therefore instantly
invalid, and will not be used another time.

Therefore every route usage afterwards will go through the routing
cache entry creation path.  And in this path the inetpeer and it's
metrics can be validated, out of date metrics freed and replaced with
new ones, etc.  Whatever might be necessary can all be done here.

There is no need to every have special handling at metric access time
on a valid routing cache entry, the fact that it's valid and it's gen
ID matches up, means there has been no route table changes meanwhile
and that the inetpeer metrics have been validated since the last route
table change.
--
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