linux-toradex.git/net/ipv4, branch v3.15.2

udp: ipv4: do not waste time in __udp4_lib_mcast_demux_lookup

2014-06-26T19:17:34+00:00

[ Upstream commit 63c6f81cdde58c41da62a8d8a209592e42a0203e ]

Its too easy to add thousand of UDP sockets on a particular bucket,
and slow down an innocent multicast receiver.

Early demux is supposed to be an optimization, we should avoid spending
too much time in it.

It is interesting to note __udp4_lib_demux_lookup() only tries to
match first socket in the chain.

10 is the threshold we already have in __udp4_lib_lookup() to switch
to secondary hash.

Fixes: 421b3885bf6d5 ("udp: ipv4: Add udp early demux")
Signed-off-by: Eric Dumazet 
Reported-by: David Held 
Cc: Shawn Bohrer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv4: fix a race in ip4_datagram_release_cb()

2014-06-26T19:17:34+00:00

[ Upstream commit 9709674e68646cee5a24e3000b3558d25412203a ]

Alexey gave a AddressSanitizer[1] report that finally gave a good hint
at where was the origin of various problems already reported by Dormando
in the past [2]

Problem comes from the fact that UDP can have a lockless TX path, and
concurrent threads can manipulate sk_dst_cache, while another thread,
is holding socket lock and calls __sk_dst_set() in
ip4_datagram_release_cb() (this was added in linux-3.8)

It seems that all we need to do is to use sk_dst_check() and
sk_dst_set() so that all the writers hold same spinlock
(sk->sk_dst_lock) to prevent corruptions.

TCP stack do not need this protection, as all sk_dst_cache writers hold
the socket lock.

[1]
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

AddressSanitizer: heap-use-after-free in ipv4_dst_check
Read of size 2 by thread T15453:
 [] ipv4_dst_check+0x1a/0x90 ./net/ipv4/route.c:1116
 [] __sk_dst_check+0x89/0xe0 ./net/core/sock.c:531
 [] ip4_datagram_release_cb+0x46/0x390 ??:0
 [] release_sock+0x17a/0x230 ./net/core/sock.c:2413
 [] ip4_datagram_connect+0x462/0x5d0 ??:0
 [] inet_dgram_connect+0x76/0xd0 ./net/ipv4/af_inet.c:534
 [] SYSC_connect+0x15c/0x1c0 ./net/socket.c:1701
 [] SyS_connect+0xe/0x10 ./net/socket.c:1682
 [] system_call_fastpath+0x16/0x1b
./arch/x86/kernel/entry_64.S:629

Freed by thread T15455:
 [] dst_destroy+0xa8/0x160 ./net/core/dst.c:251
 [] dst_release+0x45/0x80 ./net/core/dst.c:280
 [] ip4_datagram_connect+0xa1/0x5d0 ??:0
 [] inet_dgram_connect+0x76/0xd0 ./net/ipv4/af_inet.c:534
 [] SYSC_connect+0x15c/0x1c0 ./net/socket.c:1701
 [] SyS_connect+0xe/0x10 ./net/socket.c:1682
 [] system_call_fastpath+0x16/0x1b
./arch/x86/kernel/entry_64.S:629

Allocated by thread T15453:
 [] dst_alloc+0x81/0x2b0 ./net/core/dst.c:171
 [] rt_dst_alloc+0x47/0x50 ./net/ipv4/route.c:1406
 [<     inlined    >] __ip_route_output_key+0x3e8/0xf70
__mkroute_output ./net/ipv4/route.c:1939
 [] __ip_route_output_key+0x3e8/0xf70 ./net/ipv4/route.c:2161
 [] ip_route_output_flow+0x14/0x30 ./net/ipv4/route.c:2249
 [] ip4_datagram_connect+0x317/0x5d0 ??:0
 [] inet_dgram_connect+0x76/0xd0 ./net/ipv4/af_inet.c:534
 [] SYSC_connect+0x15c/0x1c0 ./net/socket.c:1701
 [] SyS_connect+0xe/0x10 ./net/socket.c:1682
 [] system_call_fastpath+0x16/0x1b
./arch/x86/kernel/entry_64.S:629

[2]
<4>[196727.311203] general protection fault: 0000 [#1] SMP
<4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode ipmi_watchdog ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis tpm tpm_bios ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit ixgbe ptp pps_core mdio
<4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 #1
<4>[196727.311344] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[196727.311364] task: ffff885e6f069700 ti: ffff885e6f072000 task.ti: ffff885e6f072000
<4>[196727.311377] RIP: 0010:[]  [] ipv4_dst_destroy+0x4f/0x80
<4>[196727.311399] RSP: 0018:ffff885effd23a70  EFLAGS: 00010282
<4>[196727.311409] RAX: dead000000200200 RBX: ffff8854c398ecc0 RCX: 0000000000000040
<4>[196727.311423] RDX: dead000000100100 RSI: dead000000100100 RDI: dead000000200200
<4>[196727.311437] RBP: ffff885effd23a80 R08: ffffffff815fd9e0 R09: ffff885d5a590800
<4>[196727.311451] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
<4>[196727.311464] R13: ffffffff81c8c280 R14: 0000000000000000 R15: ffff880e85ee16ce
<4>[196727.311510] FS:  0000000000000000(0000) GS:ffff885effd20000(0000) knlGS:0000000000000000
<4>[196727.311554] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[196727.311581] CR2: 00007a46751eb000 CR3: 0000005e65688000 CR4: 00000000000407e0
<4>[196727.311625] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[196727.311669] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[196727.311713] Stack:
<4>[196727.311733]  ffff8854c398ecc0 ffff8854c398ecc0 ffff885effd23ab0 ffffffff815b7f42
<4>[196727.311784]  ffff88be6595bc00 ffff8854c398ecc0 0000000000000000 ffff8854c398ecc0
<4>[196727.311834]  ffff885effd23ad0 ffffffff815b86c6 ffff885d5a590800 ffff8816827821c0
<4>[196727.311885] Call Trace:
<4>[196727.311907]  
<4>[196727.311912]  [] dst_destroy+0x32/0xe0
<4>[196727.311959]  [] dst_release+0x56/0x80
<4>[196727.311986]  [] tcp_v4_do_rcv+0x2a5/0x4a0
<4>[196727.312013]  [] tcp_v4_rcv+0x7da/0x820
<4>[196727.312041]  [] ? ip_rcv_finish+0x360/0x360
<4>[196727.312070]  [] ? nf_hook_slow+0x7d/0x150
<4>[196727.312097]  [] ? ip_rcv_finish+0x360/0x360
<4>[196727.312125]  [] ip_local_deliver_finish+0xb2/0x230
<4>[196727.312154]  [] ip_local_deliver+0x4a/0x90
<4>[196727.312183]  [] ip_rcv_finish+0x119/0x360
<4>[196727.312212]  [] ip_rcv+0x22b/0x340
<4>[196727.312242]  [] ? macvlan_broadcast+0x160/0x160 [macvlan]
<4>[196727.312275]  [] __netif_receive_skb_core+0x512/0x640
<4>[196727.312308]  [] ? kmem_cache_alloc+0x13b/0x150
<4>[196727.312338]  [] __netif_receive_skb+0x21/0x70
<4>[196727.312368]  [] netif_receive_skb+0x31/0xa0
<4>[196727.312397]  [] napi_gro_receive+0xe8/0x140
<4>[196727.312433]  [] ixgbe_poll+0x551/0x11f0 [ixgbe]
<4>[196727.312463]  [] ? ip_rcv+0x22b/0x340
<4>[196727.312491]  [] net_rx_action+0x111/0x210
<4>[196727.312521]  [] ? __netif_receive_skb+0x21/0x70
<4>[196727.312552]  [] __do_softirq+0xd0/0x270
<4>[196727.312583]  [] call_softirq+0x1c/0x30
<4>[196727.312613]  [] do_softirq+0x55/0x90
<4>[196727.312640]  [] irq_exit+0x55/0x60
<4>[196727.312668]  [] do_IRQ+0x63/0xe0
<4>[196727.312696]  [] common_interrupt+0x6a/0x6a
<4>[196727.312722]  
<1>[196727.313071] RIP  [] ipv4_dst_destroy+0x4f/0x80
<4>[196727.313100]  RSP 
<4>[196727.313377] ---[ end trace 64b3f14fae0f2e29 ]---
<0>[196727.380908] Kernel panic - not syncing: Fatal exception in interrupt

Reported-by: Alexey Preobrazhensky 
Reported-by: dormando 
Signed-off-by: Eric Dumazet 
Fixes: 8141ed9fcedb2 ("ipv4: Add a socket release callback for datagram sockets")
Cc: Steffen Klassert 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipip, sit: fix ipv4_{update_pmtu,redirect} calls

2014-06-26T19:17:33+00:00

[ Upstream commit 2346829e641b804ece9ac9298136b56d9567c278 ]

ipv4_{update_pmtu,redirect} were called with tunnel's ifindex (t->dev is a
tunnel netdevice). It caused wrong route lookup and failure of pmtu update or
redirect. We should use the same ifindex that we use in ip_route_output_* in
*tunnel_xmit code. It is t->parms.link .

Signed-off-by: Dmitry Popov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: tunnels - enable module autoloading

2014-06-26T19:17:33+00:00

[ Upstream commit f98f89a0104454f35a62d681683c844f6dbf4043 ]

Enable the module alias hookup to allow tunnel modules to be autoloaded on demand.

This is in line with how most other netdev kinds work, and will allow userspace
to create tunnels without having CAP_SYS_MODULE.

Signed-off-by: Tom Gundersen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: fix cwnd undo on DSACK in F-RTO

2014-06-02T23:50:49+00:00

This bug is discovered by an recent F-RTO issue on tcpm list
https://www.ietf.org/mail-archive/web/tcpm/current/msg08794.html

The bug is that currently F-RTO does not use DSACK to undo cwnd in
certain cases: upon receiving an ACK after the RTO retransmission in
F-RTO, and the ACK has DSACK indicating the retransmission is spurious,
the sender only calls tcp_try_undo_loss() if some never retransmisted
data is sacked (FLAG_ORIG_DATA_SACKED).

The correct behavior is to unconditionally call tcp_try_undo_loss so
the DSACK information is used properly to undo the cwnd reduction.

Signed-off-by: Yuchung Cheng 
Signed-off-by: Neal Cardwell 
Signed-off-by: David S. Miller

ipv4: initialise the itag variable in __mkroute_input

2014-05-22T19:57:36+00:00

the value of itag is a random value from stack, and may not be initiated by
fib_validate_source, which called fib_combine_itag if CONFIG_IP_ROUTE_CLASSID
is not set

This will make the cached dst uncertainty

Signed-off-by: Li RongQing 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller

ip_tunnel: Initialize the fallback device properly

2014-05-21T06:08:32+00:00

We need to initialize the fallback device to have a correct mtu
set on this device. Otherwise the mtu is set to null and the device
is unusable.

Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Cc: Pravin B Shelar 
Signed-off-by: Steffen Klassert 
Signed-off-by: David S. Miller

ipv4: ip_tunnels: disable cache for nbma gre tunnels

2014-05-16T20:58:41+00:00

The connected check fails to check for ip_gre nbma mode tunnels
properly. ip_gre creates temporary tnl_params with daddr specified
to pass-in the actual target on per-packet basis from neighbor
layer. Detect these tunnels by inspecting the actual tunnel
configuration.

Minimal test case:
 ip route add 192.168.1.1/32 via 10.0.0.1
 ip route add 192.168.1.2/32 via 10.0.0.2
 ip tunnel add nbma0 mode gre key 1 tos c0
 ip addr add 172.17.0.0/16 dev nbma0
 ip link set nbma0 up
 ip neigh add 172.17.0.1 lladdr 192.168.1.1 dev nbma0
 ip neigh add 172.17.0.2 lladdr 192.168.1.2 dev nbma0
 ping 172.17.0.1
 ping 172.17.0.2

The second ping should be going to 192.168.1.2 and head 10.0.0.2;
but cached gre tunnel level route is used and it's actually going
to 192.168.1.1 via 10.0.0.1.

The lladdr's need to go to separate dst for the bug to trigger.
Test case uses separate route entries, but this can also happen
when the route entry is same: if there is a nexthop exception or
the GRE tunnel is IPsec'ed in which case the dst points to xfrm
bundle unique to the gre lladdr.

Fixes: 7d442fab0a67 ("ipv4: Cache dst in tunnels")
Signed-off-by: Timo Teräs 
Cc: Tom Herbert 
Cc: Eric Dumazet 
Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

2014-05-16T03:23:48+00:00

Conflicts:
	net/ipv4/ip_vti.c

Steffen Klassert says:

====================
pull request (net): ipsec 2014-05-15

This pull request has a merge conflict in net/ipv4/ip_vti.c
between commit 8d89dcdf80d8 ("vti: don't allow to add the same
tunnel twice") and commit a32452366b72  ("vti4:Don't count header
length twice"). It can be solved like it is done in linux-next.

1) Fix a ipv6 xfrm output crash when a packet is rerouted
   by netfilter to not use IPsec.

2) vti4 counts some header lengths twice leading to an incorrect
   device mtu. Fix this by counting these headers only once.

3) We don't catch the case if an unsupported protocol is submitted
   to the xfrm protocol handlers, this can lead to NULL pointer
   dereferences. Fix this by adding the appropriate checks.

4) vti6 may unregister pernet ops twice on init errors.
   Fix this by removing one of the calls to do it only once.
   From Mathias Krause.

5) Set the vti tunnel mark before doing a lookup in the error
   handlers. Otherwise we don't find the correct xfrm state.
====================

The conflict in ip_vti.c was simple, 'net' had a commit
removing a line from vti_tunnel_init() and this tree
being merged had a commit adding a line to the same
location.

Signed-off-by: David S. Miller

vti: Use the tunnel mark for lookup in the error handlers.

2014-05-12T07:36:03+00:00

We need to use the mark we get from the tunnels o_key to
lookup the right vti state in the error handlers. This patch
ensures that.

Fixes: df3893c1 ("vti: Update the ipv4 side to use it's own receive hook.")
Fixes: fa9ad96d ("vti6: Update the ipv6 side to use its own receive hook.")
Signed-off-by: Steffen Klassert