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

On 07/03/2012 5:05 AM, David Miller wrote:

From: Nick Jones <redacted>
Date: Tue, 06 Mar 2012 23:49:31 +0800

quoted

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.

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.