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
| ||
|
Message-ID: <20150205072125.GY13046@secunet.com> Date: Thu, 5 Feb 2015 08:21:25 +0100 From: Steffen Klassert <steffen.klassert@...unet.com> To: shengyong <shengyong1@...wei.com> CC: <davem@...emloft.net>, <netdev@...r.kernel.org>, <yangyingliang@...wei.com>, <hannes@...hat.com> Subject: Re: Question: should local address be expired when updating PMTU? On Wed, Feb 04, 2015 at 09:59:54AM +0800, shengyong wrote: > > Sorry, the later. I test it on 3.10-stable. It can fix this problem. So maybe this is a bug? Yes, it's a bug. > And the 3 approaches (different flags are used: RTF_LOCAL, IFF_LOOPBACK and RTF_CACHE) in > these mails can fix the expire of local address. I'm confused about these flags: > * RTF_LOCAL: the entries of local address, like address binded to the native NIC > * RTF_CACHE: all cached entries > * IFF_LOOPBACK: this is a device-related flag, which has the same meaning as RTF_LOCAL > > Am I right? If so, I think RTF_LOCAL is appropriate, because we just want entries of local > addresses to be not expired and we don't care other entries (I think if they get expired, > a neigh discovery could find them back). It is not the address that expires, it is the learned PMTU value that expires. If we delete an uncached route, nothing will bring it back unless you readd it manually. We need to ensure that all routes that can learn something what expires are cached. This means that we clone the inserted route when it is used for the first time. The learned values are stored at this cloned route. If the learned value expires, the clone is deleted. The original route remains in the fib tree and can be still looked up. The problem is, that we currently don't cache/clone host routes. So if a host route learns something that expires, the original route is removed from the fib tree and we loose connectivity to that host. We don't cache host routes because some of them (the local ones) are automatically added with metric 0. If we try to cache such a route, the clone will be identical to the original route and we fail to insert it to the fib tree. So we need to adjust the caching to all routes that actually can learn something and leave out only those that can not. I'll send a patchset that should fix this at the beginning of the next week. -- 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