linux/include/net/ip6_fib.h, branch v3.0.86

net: Remove KERNEL cpp checks from include/net

2011-04-24T17:54:56Z

These header files are never installed to user consumption, so any __KERNEL__ cpp checks are superfluous. Projects should also not copy these files into their userland utility sources and try to use them there. If they insist on doing so, the onus is on them to sanitize the headers as needed. Signed-off-by: David S. Miller

inet: constify ip headers and in6_addr

2011-04-22T18:04:14Z

Add const qualifiers to structs iphdr, ipv6hdr and in6_addr pointers where possible, to make code intention more obvious. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

ipv6: RTA_PREFSRC support for ipv6 route source address selection

2011-04-15T22:44:37Z

[ipv6] Add support for RTA_PREFSRC This patch allows a user to select the preferred source address for a specific IPv6-Route. It can be set via a netlink message setting RTA_PREFSRC to a valid IPv6 address which must be up on the device the route will be bound to. Signed-off-by: Daniel Walter Signed-off-by: David S. Miller

ipv6: Convert to use flowi6 where applicable.

2011-03-12T23:08:54Z

Signed-off-by: David S. Miller

inet: Create a mechanism for upward inetpeer propagation into routes.

2011-02-10T21:33:41Z

If we didn't have a routing cache, we would not be able to properly propagate certain kinds of dynamic path attributes, for example PMTU information and redirects. The reason is that if we didn't have a routing cache, then there would be no way to lookup all of the active cached routes hanging off of sockets, tunnels, IPSEC bundles, etc. Consider the case where we created a cached route, but no inetpeer entry existed and also we were not asked to pre-COW the route metrics and therefore did not force the creation a new inetpeer entry. If we later get a PMTU message, or a redirect, and store this information in a new inetpeer entry, there is no way to teach that cached route about the newly existing inetpeer entry. The facilities implemented here handle this problem. First we create a generation ID. When we create a cached route of any kind, we remember the generation ID at the time of attachment. Any time we force-create an inetpeer entry in response to new path information, we bump that generation ID. The dst_ops->check() callback is where the knowledge of this event is propagated. If the global generation ID does not equal the one stored in the cached route, and the cached route has not attached to an inetpeer yet, we look it up and attach if one is found. Now that we've updated the cached route's information, we update the route's generation ID too. This clears the way for implementing PMTU and redirects directly in the inetpeer cache. There is absolutely no need to consult cached route information in order to maintain this information. At this point nothing bumps the inetpeer genids, that comes in the later changes which handle PMTUs and redirects using inetpeers. Signed-off-by: David S. Miller

ipv6: Add infrastructure to bind inet_peer objects to routes.

2010-11-30T20:27:11Z

They are only allowed on cached ipv6 routes. Signed-off-by: David S. Miller

net-next: remove useless union keyword

2010-06-11T06:31:35Z

remove useless union keyword in rtable, rt6_info and dn_route. Since there is only one member in a union, the union keyword isn't useful. Signed-off-by: Changli Gao Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

ipv6 fib: Make rt6_info{} more cache-line aware.

2010-04-02T01:41:41Z

The head element of rt6_info{} is dst_entry{}, and IPv6 specific elements follow. Because elements at the end of dst_entry{} are frequently updated, it is not good to put frequently-used static elements, such as rt6i_idev, rt6i_dst or rt6i_flags in the same cache line. On the other hand, fib6_table, rt6i_node or rt6i_gateway are rarely used, so it is okay to stay in the same cache line. Let's rearrange rt6_info{}. Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller

ipv6: use standard lists for FIB walks

2010-02-18T22:30:17Z

Signed-off-by: Alexey Dobriyan Signed-off-by: David S. Miller

ipv6: fib: fix crash when changing large fib while dumping it

2010-02-12T20:06:35Z

When the fib size exceeds what can be dumped in a single skb, the dump is suspended and resumed once the last skb has been received by userspace. When the fib is changed while the dump is suspended, the walker might contain stale pointers, causing a crash when the dump is resumed. BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: [] fib6_walk_continue+0xbb/0x124 [ipv6] PGD 5347a067 PUD 65c7067 PMD 0 Oops: 0000 [#1] PREEMPT SMP ... RIP: 0010:[] [] fib6_walk_continue+0xbb/0x124 [ipv6] ... Call Trace: [] ? mutex_spin_on_owner+0x59/0x71 [] inet6_dump_fib+0x11b/0x1b9 [ipv6] [] netlink_dump+0x5b/0x19e [] ? consume_skb+0x28/0x2a [] netlink_recvmsg+0x1ab/0x2c6 [] ? netlink_unicast+0xfa/0x151 [] __sock_recvmsg+0x6d/0x79 [] sock_recvmsg+0xca/0xe3 [] ? autoremove_wake_function+0x0/0x38 [] ? radix_tree_lookup_slot+0xe/0x10 [] ? find_get_page+0x90/0xa5 [] ? filemap_fault+0x201/0x34f [] ? fget_light+0x2f/0xac [] ? verify_iovec+0x4f/0x94 [] sys_recvmsg+0x14d/0x223 Store the serial number when beginning to walk the fib and reload pointers when continuing to walk after a change occured. Similar to other dumping functions, this might cause unrelated entries to be missed when entries are deleted. Tested-by: Ben Greear Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller