linux-stable.git/net/ipv4/fib_semantics.c, branch v4.4

net: Fix prefsrc lookups

2015-11-05T02:34:37+00:00

A bug report (https://bugzilla.kernel.org/show_bug.cgi?id=107071) noted
that the follwoing ip command is failing with v4.3:

    $ ip route add 10.248.5.0/24 dev bond0.250 table vlan_250 src 10.248.5.154
    RTNETLINK answers: Invalid argument

021dd3b8a142d changed the lookup of the given preferred source address to
use the table id passed in, but this assumes the local entries are in the
given table which is not necessarily true for non-VRF use cases. When
validating the preferred source fallback to the local table on failure.

Fixes: 021dd3b8a142d ("net: Add routes to the table associated with the device")
Signed-off-by: David Ahern 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2015-11-03T18:41:45+00:00

Minor overlapping changes in net/ipv4/ipmr.c, in 'net' we were
fixing the "BH-ness" of the counter bumps whilst in 'net-next'
the functions were modified to take an explicit 'net' parameter.

Signed-off-by: David S. Miller

ipv4: use l4 hash for locally generated multipath flows

2015-11-02T19:38:43+00:00

This patch changes how the multipath hash is computed for locally
generated flows: now the hash comprises l4 information.

This allows better utilization of the available paths when the existing
flows have the same source IP and the same destination IP: with l3 hash,
even when multiple connections are in place simultaneously, a single path
will be used, while with l4 hash we can use all the available paths.

v2 changes:
- use get_hash_from_flowi4() instead of implementing just another l4 hash
  function

Signed-off-by: Paolo Abeni 
Signed-off-by: David S. Miller

ipv4: update RTNH_F_LINKDOWN flag on UP event

2015-11-01T21:57:39+00:00

When nexthop is part of multipath route we should clear the
LINKDOWN flag when link goes UP or when first address is added.
This is needed because we always set LINKDOWN flag when DEAD flag
was set but now on UP the nexthop is not dead anymore. Examples when
LINKDOWN bit can be forgotten when no NETDEV_CHANGE is delivered:

- link goes down (LINKDOWN is set), then link goes UP and device
shows carrier OK but LINKDOWN remains set

- last address is deleted (LINKDOWN is set), then address is
added and device shows carrier OK but LINKDOWN remains set

Steps to reproduce:
modprobe dummy
ifconfig dummy0 192.168.168.1 up

here add a multipath route where one nexthop is for dummy0:

ip route add 1.2.3.4 nexthop dummy0 nexthop SOME_OTHER_DEVICE
ifconfig dummy0 down
ifconfig dummy0 up

now ip route shows nexthop that is not dead. Now set the sysctl var:

echo 1 > /proc/sys/net/ipv4/conf/dummy0/ignore_routes_with_linkdown

now ip route will show a dead nexthop because the forgotten
RTNH_F_LINKDOWN is propagated as RTNH_F_DEAD.

Fixes: 8a3d03166f19 ("net: track link-status of ipv4 nexthops")
Signed-off-by: Julian Anastasov 
Signed-off-by: David S. Miller

ipv4: fix to not remove local route on link down

2015-11-01T21:57:39+00:00

When fib_netdev_event calls fib_disable_ip on NETDEV_DOWN event
we should not delete the local routes if the local address
is still present. The confusion comes from the fact that both
fib_netdev_event and fib_inetaddr_event use the NETDEV_DOWN
constant. Fix it by returning back the variable 'force'.

Steps to reproduce:
modprobe dummy
ifconfig dummy0 192.168.168.1 up
ifconfig dummy0 down
ip route list table local | grep dummy | grep host
local 192.168.168.1 dev dummy0  proto kernel  scope host  src 192.168.168.1

Fixes: 8a3d03166f19 ("net: track link-status of ipv4 nexthops")
Signed-off-by: Julian Anastasov 
Signed-off-by: David S. Miller

net: Fix suspicious RCU usage in fib_rebalance

2015-10-16T07:57:55+00:00

This command:
  ip route add 192.168.1.0/24 nexthop via 10.2.1.5 dev eth1 nexthop via 10.2.2.5 dev eth2

generated this suspicious RCU usage message:

[ 63.249262]
[ 63.249939] ===============================
[ 63.251571] [ INFO: suspicious RCU usage. ]
[ 63.253250] 4.3.0-rc3+ #298 Not tainted
[ 63.254724] -------------------------------
[ 63.256401] ../include/linux/inetdevice.h:205 suspicious rcu_dereference_check() usage!
[ 63.259450]
[ 63.259450] other info that might help us debug this:
[ 63.259450]
[ 63.262297]
[ 63.262297] rcu_scheduler_active = 1, debug_locks = 1
[ 63.264647] 1 lock held by ip/2870:
[ 63.265896] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x14
[ 63.268858]
[ 63.268858] stack backtrace:
[ 63.270409] CPU: 4 PID: 2870 Comm: ip Not tainted 4.3.0-rc3+ #298
[ 63.272478] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 63.275745] 0000000000000001 ffff8800b8c9f8b8 ffffffff8125f73c ffff88013afcf301
[ 63.278185] ffff8800bab7a380 ffff8800b8c9f8e8 ffffffff8107bf30 ffff8800bb728000
[ 63.280634] ffff880139fe9a60 0000000000000000 ffff880139fe9a00 ffff8800b8c9f908
[ 63.283177] Call Trace:
[ 63.283959] [] dump_stack+0x4c/0x68
[ 63.285593] [] lockdep_rcu_suspicious+0xfa/0x103
[ 63.287500] [] __in_dev_get_rcu+0x48/0x4f
[ 63.289169] [] fib_rebalance+0x3e/0x127
[ 63.290753] [] ? rcu_read_unlock+0x3e/0x5f
[ 63.292442] [] fib_create_info+0xaf9/0xdcc
[ 63.294093] [] ? sched_clock_local+0x12/0x75
[ 63.295791] [] fib_table_insert+0x8c/0x451
[ 63.297493] [] ? fib_get_table+0x36/0x43
[ 63.299109] [] inet_rtm_newroute+0x43/0x51
[ 63.300709] [] rtnetlink_rcv_msg+0x182/0x195
[ 63.302334] [] ? trace_hardirqs_on+0xd/0xf
[ 63.303888] [] ? rtnl_lock+0x12/0x14
[ 63.305346] [] ? __rtnl_unlock+0x12/0x12
[ 63.306878] [] netlink_rcv_skb+0x3d/0x90
[ 63.308437] [] rtnetlink_rcv+0x21/0x28
[ 63.309916] [] netlink_unicast+0xfa/0x17f
[ 63.311447] [] netlink_sendmsg+0x297/0x2dc
[ 63.313029] [] sock_sendmsg_nosec+0x12/0x1d
[ 63.314597] [] ___sys_sendmsg+0x196/0x21b
[ 63.316125] [] ? native_sched_clock+0x1f/0x3c
[ 63.317671] [] ? sched_clock_local+0x12/0x75
[ 63.319185] [] ? sched_clock_cpu+0x9d/0xb6
[ 63.320693] [] ? __lock_is_held+0x32/0x54
[ 63.322145] [] ? __fget_light+0x4b/0x77
[ 63.323541] [] __sys_sendmsg+0x3d/0x5b
[ 63.324947] [] SyS_sendmsg+0xd/0x19
[ 63.326274] [] entry_SYSCALL_64_fastpath+0x12/0x6f

It looks like all of the code paths to fib_rebalance are under rtnl.

Fixes: 0e884c78ee19 ("ipv4: L3 hash-based multipath")
Cc: Peter Nørlund 
Signed-off-by: David Ahern 
Signed-off-by: David S. Miller

net: Refactor path selection in __ip_route_output_key_hash

2015-10-07T11:27:44+00:00

VRF device needs the same path selection following lookup to set source
address. Rather than duplicating code, move existing code into a
function that is exported to modules.

Code move only; no functional change.

Signed-off-by: David Ahern 
Signed-off-by: David S. Miller

ipv4: Fix compilation errors in fib_rebalance

2015-10-06T06:48:09+00:00

This fixes

net/built-in.o: In function `fib_rebalance':
fib_semantics.c:(.text+0x9df14): undefined reference to `__divdi3'

and

net/built-in.o: In function `fib_rebalance':
net/ipv4/fib_semantics.c:572: undefined reference to `__aeabi_ldivmod'

Fixes: 0e884c78ee19 ("ipv4: L3 hash-based multipath")

Signed-off-by: Peter Nørlund 
Signed-off-by: David S. Miller

ipv4: L3 hash-based multipath

2015-10-05T09:59:21+00:00

Replaces the per-packet multipath with a hash-based multipath using
source and destination address.

Signed-off-by: Peter Nørlund 
Signed-off-by: David S. Miller

net: Make table id type u32

2015-09-01T21:32:44+00:00

A number of VRF patches used 'int' for table id. It should be u32 to be
consistent with the rest of the stack.

Fixes:
4e3c89920cd3a ("net: Introduce VRF related flags and helpers")
15be405eb2ea9 ("net: Add inet_addr lookup by table")
30bbaa1950055 ("net: Fix up inet_addr_type checks")
021dd3b8a142d ("net: Add routes to the table associated with the device")
dc028da54ed35 ("inet: Move VRF table lookup to inlined function")
f6d3c19274c74 ("net: FIB tracepoints")

Signed-off-by: David Ahern 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller