Re: [PATCH net-next] ipv6: perform inetpeer binding at dst creation, with readonly option

[Nick Jones <nick.jones@network-box.com>]

On 07/03/2012 5:05 AM, David Miller wrote:
> From: Nick Jones <nick.jones@network-box.com>
> 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 <nick.jones@network-box.com>
> 
> 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.

Sure, I'm testing a patch that follows this suggestion and will submit it
soon.

However, seeing a kmalloc done for such a transient, sparse structure didn't
sit so well in the stomach.  If we can be sure that the metrics of a dst for
an icmp6 packet won't be written to, we could use the static const
ip6_template_metrics array defined in route.c:~205, it has RTAX_HOPLIMIT
fixed at 255, and using it avoids a kmalloc.

I'll produce another patch for this strategy if you think this is a better idea.