Thread (4 messages) flat view 4 messages, 2 authors, 2012-03-08

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help