netdev - Re: linux-3.0.x regression with ipv4 routes having mtu

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: <20111219.150903.108164273331779302.davem@davemloft.net>
Date:	Mon, 19 Dec 2011 15:09:03 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	steffen.klassert@...unet.com
Cc:	timo.teras@....fi, netdev@...r.kernel.org
Subject: Re: linux-3.0.x regression with ipv4 routes having mtu

From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Mon, 19 Dec 2011 14:52:59 +0100

> On Fri, Dec 16, 2011 at 04:30:26PM +0200, Timo Teräs wrote:
>> On 12/16/2011 02:21 PM, Steffen Klassert wrote:
>> > 
>> > "ip route flush cache" does not even flush the routing cache,
>> > it just markes the routing cache as invalid by changing the
>> > rt_genid which make the old routes invisible. And since we don't
>> > have rt_check_expire() anymore, we have to wait until we have
>> > collected gc_thresh (1024) useless routes before rt_garbage_collect()
>> > starts to remove some of them (btw. is this intentional).
>> > 
>> > I think we need a trigger in rt_cache_invalidate() that expires
>> > all cached pmtu values similar to the routing cache entries.
>> > For a moment I thought we could just reset the __rt_peer_genid
>> > value back to zero to mark all cached pmtu values as expired,
>> > but that's apparently not save to do. So I came to no conclusion
>> > how to fix this today. Any ideas?
>> 
>> Oh, right. This problem is secondary. As long as the mtu value is
>> reflected properly, I'll be happy :)
>> 
> 
> Well, "ip route flush cache" flushed the cached pmtu informations
> in 2.6.38 and before, now it does not do it anymore. I guess
> some users rely on the old behaviour, so it would be nice if we
> could restore it. I think we can fix this by adding a pmtu_genid,
> exactly in the same way as we have now the redirect_genid.
> I'll give this a try.

Actually, adding yet another ID is pointless.

Just get rid of redirect_genid, and use net->ipv4.rt_genid for all of
the necessary purposes.  Let there be one ID in the inetpeer and use
the net->ipv4.rt_genid to drive it.

--
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