linux-stable.git/net/ipv6/route.c, branch linux-3.4.y

ipv6: fix handling of blackhole and prohibit routes

2016-10-26T15:15:43+00:00

commit ef2c7d7b59708d54213c7556a82d14de9a7e4475 upstream.

When adding a blackhole or a prohibit route, they were handling like classic
routes. Moreover, it was only possible to add this kind of routes by specifying
an interface.

Bug already reported here:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498498

Before the patch:
  $ ip route add blackhole 2001::1/128
  RTNETLINK answers: No such device
  $ ip route add blackhole 2001::1/128 dev eth0
  $ ip -6 route | grep 2001
  2001::1 dev eth0  metric 1024

After:
  $ ip route add blackhole 2001::1/128
  $ ip -6 route | grep 2001
  blackhole 2001::1 dev lo  metric 1024  error -22

v2: wrong patch
v3: add a field fc_type in struct fib6_config to store RTN_* type

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Zefan Li

ipv6: update ip6_rt_last_gc every time GC is run

2016-10-26T15:15:43+00:00

commit 49a18d86f66d33a20144ecb5a34bba0d1856b260 upstream.

As pointed out by Eric Dumazet, net->ipv6.ip6_rt_last_gc should
hold the last time garbage collector was run so that we should
update it whenever fib6_run_gc() calls fib6_clean_all(), not only
if we got there from ip6_dst_gc().

Signed-off-by: Michal Kubecek 
Signed-off-by: David S. Miller 
Signed-off-by: Zefan Li

ipv6: prevent fib6_run_gc() contention

2016-03-21T01:17:57+00:00

commit 2ac3ac8f86f2fe065d746d9a9abaca867adec577 upstream.

On a high-traffic router with many processors and many IPv6 dst
entries, soft lockup in fib6_run_gc() can occur when number of
entries reaches gc_thresh.

This happens because fib6_run_gc() uses fib6_gc_lock to allow
only one thread to run the garbage collector but ip6_dst_gc()
doesn't update net->ipv6.ip6_rt_last_gc until fib6_run_gc()
returns. On a system with many entries, this can take some time
so that in the meantime, other threads pass the tests in
ip6_dst_gc() (ip6_rt_last_gc is still not updated) and wait for
the lock. They then have to run the garbage collector one after
another which blocks them for quite long.

Resolve this by replacing special value ~0UL of expire parameter
to fib6_run_gc() by explicit "force" parameter to choose between
spin_lock_bh() and spin_trylock_bh() and call fib6_run_gc() with
force=false if gc_thresh is reached but not max_size.

Signed-off-by: Michal Kubecek 
Signed-off-by: David S. Miller 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ipv6: probe routes asynchronous in rt6_probe

2016-03-21T01:17:56+00:00

commit c2f17e827b419918c856131f592df9521e1a38e3 upstream.

Routes need to be probed asynchronous otherwise the call stack gets
exhausted when the kernel attemps to deliver another skb inline, like
e.g. xt_TEE does, and we probe at the same time.

We update neigh->updated still at once, otherwise we would send to
many probes.

Cc: Julian Anastasov 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ipv6: add check for blackhole or prohibited entry in rt6_redire

2015-09-14T01:27:08+00:00

There's a check for ip6_null_entry, but it's not enough if the config
CONFIG_IPV6_MULTIPLE_TABLES is selected. Blackhole or prohibited entries
should also be ignored.

This path is for kernel before v3.6, as there's a commit b94f1c0
use icmpv6_notify() instead of rt6_redirect() and rt6_redirect has
been deleted.

The oops as follow:
    [exception RIP: do_raw_write_lock+12]
    RIP: ffffffff8122c42c  RSP: ffff880666e45820  RFLAGS: 00010282
    RAX: ffff8801207bffd8  RBX: 0000000000000018  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: ffff880666e45898  RDI: 0000000000000018
    RBP: ffff880666e45830   R8: 000000000000001e   R9: 0000000006000000
    R10: ffff88011796b8a0  R11: 0000000000000004  R12: ffff88010391ed00
    R13: 0000000000000000  R14: ffff880666e45898  R15: ffff88011796b890
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    [ffff880666e45838] _raw_write_lock_bh at ffffffff81450b39
    [ffff880666e45858] __ip6_ins_rt at ffffffff813ed8c1
    [ffff880666e45888] ip6_ins_rt at ffffffff813eef58
    [ffff880666e458b8] rt6_redirect at ffffffff813f0b84
    [ffff880666e45958] ndisc_rcv at ffffffff813f95d8
    [ffff880666e45a08] icmpv6_rcv at ffffffff814000e8
    [ffff880666e45ae8] ip6_input_finish at ffffffff813e43bb
    [ffff880666e45b38] ip6_input at ffffffff813e4b08
    [ffff880666e45b68] ipv6_rcv at ffffffff813e4969
    [ffff880666e45bc8] __netif_receive_skb at ffffffff8135158a
    [ffff880666e45c38] dev_gro_receive at ffffffff81351cb0
    [ffff880666e45c78] napi_gro_receive at ffffffff81351fc5
    [ffff880666e45cb8] tg3_rx at ffffffffa0bfb354 [tg]
    [ffff880666e45d88] tg3_poll_work at ffffffffa0c07857 [tg]
    [ffff880666e45e18] tg3_poll_msix at ffffffffa0c07d1b [tg]
    [ffff880666e45e68] net_rx_action at ffffffff81352219
    [ffff880666e45ec8] __do_softirq at ffffffff8103e5a1
    [ffff880666e45f38] call_softirq at ffffffff81459c4c
    [ffff880666e45f50] do_softirq at ffffffff8100413d
    [ffff880666e45f80] do_IRQ at ffffffff81003cce
This happened when ip6_route_redirect found a rt which was set
blackhole, the rt had a NULL rt6i_table argument which is accessed by
__ip6_ins_rt() when trying to lock rt6i_table->tb6_lock caused a BUG:
"BUG: unable to handle kernel NULL pointer"

Signed-off-by: Weilong Chen

ipv6: fix ipv6_cow_metrics for non DST_HOST case

2015-06-19T03:40:17+00:00

commit 3b4711757d7903ab6fa88a9e7ab8901b8227da60 upstream.

ipv6_cow_metrics() currently assumes only DST_HOST routes require
dynamic metrics allocation from inetpeer.  The assumption breaks
when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
is called after the route is created.

This patch creates the metrics array (by calling dst_cow_metrics_generic) in
ipv6_cow_metrics().

Test:
radvd.conf:
interface qemubr0
{
	AdvLinkMTU 1300;
	AdvCurHopLimit 30;

	prefix fd00:face:face:face::/64
	{
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;
	};
};

Before:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0  proto kernel  metric 256  expires 27sec
fe80::/64 dev eth0  proto kernel  metric 256
default via fe80::74df:d0ff:fe23:8ef2 dev eth0  proto ra  metric 1024  expires 27sec

After:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0  proto kernel  metric 256  expires 27sec mtu 1300
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1300
default via fe80::74df:d0ff:fe23:8ef2 dev eth0  proto ra  metric 1024  expires 27sec mtu 1300 hoplimit 30

Fixes: 8e2ec639173f325 (ipv6: don't use inetpeer to store metrics for routes.)
Signed-off-by: Martin KaFai Lau 
Signed-off-by: David S. Miller 
Signed-off-by: Zefan Li

ipv6: Limit mtu to 65575 bytes

2014-06-07T23:01:59+00:00

[ Upstream commit 30f78d8ebf7f514801e71b88a10c948275168518 ]

Francois reported that setting big mtu on loopback device could prevent
tcp sessions making progress.

We do not support (yet ?) IPv6 Jumbograms and cook corrupted packets.

We must limit the IPv6 MTU to (65535 + 40) bytes in theory.

Tested:

ifconfig lo mtu 70000
netperf -H ::1

Before patch : Throughput :   0.05 Mbits

After patch : Throughput : 35484 Mbits

Reported-by: Francois WELLENREITER 
Signed-off-by: Eric Dumazet 
Acked-by: YOSHIFUJI Hideaki 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: don't set DST_NOCOUNT for remotely added routes

2014-04-27T00:13:16+00:00

[ Upstream commit c88507fbad8055297c1d1e21e599f46960cbee39 ]

DST_NOCOUNT should only be used if an authorized user adds routes
locally. In case of routes which are added on behalf of router
advertisments this flag must not get used as it allows an unlimited
number of routes getting added remotely.

Signed-off-by: Sabrina Dubroca 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: don't count addrconf generated routes against gc limit

2014-01-15T23:27:10+00:00

[ Upstream commit a3300ef4bbb1f1e33ff0400e1e6cf7733d988f4f ]

Brett Ciphery reported that new ipv6 addresses failed to get installed
because the addrconf generated dsts where counted against the dst gc
limit. We don't need to count those routes like we currently don't count
administratively added routes.

Because the max_addresses check enforces a limit on unbounded address
generation first in case someone plays with router advertisments, we
are still safe here.

Reported-by: Brett Ciphery 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: use rt6_get_dflt_router to get default router in rt6_route_rcv

2013-12-08T15:29:41+00:00

[ Upstream commit f104a567e673f382b09542a8dc3500aa689957b4 ]

As the rfc 4191 said, the Router Preference and Lifetime values in a
::/0 Route Information Option should override the preference and lifetime
values in the Router Advertisement header. But when the kernel deals with
a ::/0 Route Information Option, the rt6_get_route_info() always return
NULL, that means that overriding will not happen, because those default
routers were added without flag RTF_ROUTEINFO in rt6_add_dflt_router().

In order to deal with that condition, we should call rt6_get_dflt_router
when the prefix length is 0.

Signed-off-by: Duan Jiong 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman