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
| ||
|
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
Powered by blists - more mailing lists