Re: [PATCH net-next] ipv6: perform inetpeer binding at dst creation, with readonly option
From: David Miller <davem@davemloft.net>
Date: 2012-03-06 21:05:53
From: Nick Jones <redacted> Date: Tue, 06 Mar 2012 23:49:31 +0800
A neighbour advertises itself as obsolete and at a later time, the host sends solicitations to the neighbours direct address. The NS icmp6 packets have hoplimit explicitly set to 255. The neighbour re-advertises itself. All subsequent packets sent to the neighbour address will now have hoplimit stuck at 255 because the setup of the NS packet wrote 255 to the cached metrics of the inetpeer that the neighbour address' ip6_dst was bound to. If the neighbour was a router, a RA that attempts to update the hoplimit for the route will have no effect because of the way ip6_dst_hoplimit works. This patch adds an rt6_init_metrics method that is called shortly after a call to ip6_dst_alloc, it performs the inetpeer binding at that time. It allows the caller to indicate whether they want the new ip6_dst metrics, and thus the inetpeer metrics, to be writable. icmp6_dst_alloc will now no longer permanently alter the peer metrics. Signed-off-by: Nick Jones <redacted>
So we essentially have two views of the same inetpeer. I would say that the real fix for this is to just use kmalloc'd metrics for these special icmp6 dsts and leave the rest of the code alone.