linux-stable.git/net/core, branch v3.16.50

ipv4: add reference counting to metrics

2017-11-11T13:33:21+00:00

commit 3fb07daff8e99243366a081e5129560734de4ada upstream.

Andrey Konovalov reported crashes in ipv4_mtu()

I could reproduce the issue with KASAN kernels, between
10.246.7.151 and 10.246.7.152 :

1) 20 concurrent netperf -t TCP_RR -H 10.246.7.152 -l 1000 &

2) At the same time run following loop :
while :
do
 ip ro add 10.246.7.152 dev eth0 src 10.246.7.151 mtu 1500
 ip ro del 10.246.7.152 dev eth0 src 10.246.7.151 mtu 1500
done

Cong Wang attempted to add back rt->fi in commit
82486aa6f1b9 ("ipv4: restore rt->fi for reference counting")
but this proved to add some issues that were complex to solve.

Instead, I suggested to add a refcount to the metrics themselves,
being a standalone object (in particular, no reference to other objects)

I tried to make this patch as small as possible to ease its backport,
instead of being super clean. Note that we believe that only ipv4 dst
need to take care of the metric refcount. But if this is wrong,
this patch adds the basic infrastructure to extend this to other
families.

Many thanks to Julian Anastasov for reviewing this patch, and Cong Wang
for his efforts on this problem.

Fixes: 2860583fe840 ("ipv4: Kill rt->fi")
Signed-off-by: Eric Dumazet 
Reported-by: Andrey Konovalov 
Reviewed-by: Julian Anastasov 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16:
 - Give DST_METRICS_REFCOUNTED a value of 4 and struct dst_metrics an
   alignment of 8
 - Update dst_metrics cache size
 - Adjust context]
Signed-off-by: Ben Hutchings

dst: Increase alignment of metrics to allow extra flag on pointers

2017-11-11T13:33:20+00:00

For the backport of "ipv4: add reference counting to metrics", we will
need a third flag on metrics pointers.  This was not needed upstream
as the DST_METRICS_FORCE_OVERWRITE flag has been eliminated there.
In order to use three flag bits we need to increase the alignment of
metrics from 4 to 8 bytes.

Signed-off-by: Ben Hutchings

net: avoid skb_warn_bad_offload false positives on UFO

2017-11-11T13:33:18+00:00

commit 8d63bee643f1fb53e472f0e135cae4eb99d62d19 upstream.

skb_warn_bad_offload triggers a warning when an skb enters the GSO
stack at __skb_gso_segment that does not have CHECKSUM_PARTIAL
checksum offload set.

Commit b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
observed that SKB_GSO_DODGY producers can trigger the check and
that passing those packets through the GSO handlers will fix it
up. But, the software UFO handler will set ip_summed to
CHECKSUM_NONE.

When __skb_gso_segment is called from the receive path, this
triggers the warning again.

Make UFO set CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE. On
Tx these two are equivalent. On Rx, this better matches the
skb state (checksum computed), as CHECKSUM_NONE here means no
checksum computed.

See also this thread for context:
http://patchwork.ozlabs.org/patch/799015/

Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

net: skb_needs_check() accepts CHECKSUM_NONE for tx

2017-11-11T13:33:18+00:00

commit 6e7bc478c9a006c701c14476ec9d389a484b4864 upstream.

My recent change missed fact that UFO would perform a complete
UDP checksum before segmenting in frags.

In this case skb->ip_summed is set to CHECKSUM_NONE.

We need to add this valid case to skb_needs_check()

Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Eric Dumazet 
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: reduce skb_warn_bad_offload() noise

2017-11-11T13:33:17+00:00

commit b2504a5dbef3305ef41988ad270b0e8ec289331c upstream.

Dmitry reported warnings occurring in __skb_gso_segment() [1]

All SKB_GSO_DODGY producers can allow user space to feed
packets that trigger the current check.

We could prevent them from doing so, rejecting packets, but
this might add regressions to existing programs.

It turns out our SKB_GSO_DODGY handlers properly set up checksum
information that is needed anyway when packets needs to be segmented.

By checking again skb_needs_check() after skb_mac_gso_segment(),
we should remove these pesky warnings, at a very minor cost.

With help from Willem de Bruijn

[1]
WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
 ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
 ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
 ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 [] panic+0x1fb/0x412 kernel/panic.c:179
 [] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
 [] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
 [] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
 [] skb_gso_segment include/linux/netdevice.h:3985 [inline]
 [] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
 [] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
 [] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 [] packet_snd net/packet/af_packet.c:2930 [inline]
 [] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
 [] sock_sendmsg_nosec net/socket.c:621 [inline]
 [] sock_sendmsg+0xca/0x110 net/socket.c:631
 [] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
 [] __sys_sendmsg+0x138/0x300 net/socket.c:1988
 [] SYSC_sendmsg net/socket.c:1999 [inline]
 [] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2

Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov  
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: remove open-coded skb_cow_head.

2017-11-11T13:33:17+00:00

commit a40e0a664bce465a3b8ad1d792153cef8ded9f7d upstream.

Signed-off-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()

2017-09-15T17:30:16+00:00

commit e44699d2c28067f69698ccb68dd3ddeacfebc434 upstream.

Recently I started seeing warnings about pages with refcount -1. The
problem was traced to packets being reused after their head was merged into
a GRO packet by skb_gro_receive(). While bisecting the issue pointed to
commit c21b48cc1bbf ("net: adjust skb->truesize in ___pskb_trim()") and
I have never seen it on a kernel with it reverted, I believe the real
problem appeared earlier when the option to merge head frag in GRO was
implemented.

Handling NAPI_GRO_FREE_STOLEN_HEAD state was only added to GRO_MERGED_FREE
branch of napi_skb_finish() so that if the driver uses napi_gro_frags()
and head is merged (which in my case happens after the skb_condense()
call added by the commit mentioned above), the skb is reused including the
head that has been merged. As a result, we release the page reference
twice and eventually end up with negative page refcount.

To fix the problem, handle NAPI_GRO_FREE_STOLEN_HEAD in napi_frags_finish()
the same way it's done in napi_skb_finish().

Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
Signed-off-by: Michal Kubecek 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: The necessary cleanup is just kmem_cache_free(),
 so don't bother adding a function for this.]
Signed-off-by: Ben Hutchings

net: prevent sign extension in dev_get_stats()

2017-09-15T17:30:16+00:00

commit 6f64ec74515925cced6df4571638b5a099a49aae upstream.

Similar to the fix provided by Dominik Heidler in commit
9b3dc0a17d73 ("l2tp: cast l2tp traffic counter to unsigned")
we need to take care of 32bit kernels in dev_get_stats().

When using atomic_long_read(), we add a 'long' to u64 and
might misinterpret high order bit, unless we cast to unsigned.

Fixes: caf586e5f23ce ("net: add a core netdev->rx_dropped counter")
Fixes: 015f0688f57ca ("net: net: add a core netdev->tx_dropped counter")
Fixes: 6e7333d315a76 ("net: add rx_nohandler stat counter")
Signed-off-by: Eric Dumazet 
Cc: Jarod Wilson 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: only {rx,tx}_dropped are updated here]
Signed-off-by: Ben Hutchings

rtnetlink: add IFLA_GROUP to ifla_policy

2017-09-15T17:30:13+00:00

commit db833d40ad3263b2ee3b59a1ba168bb3cfed8137 upstream.

Network interface groups support added while ago, however
there is no IFLA_GROUP attribute description in policy
and netlink message size calculations until now.

Add IFLA_GROUP attribute to the policy.

Fixes: cbda10fa97d7 ("net_device: add support for network device groups")
Signed-off-by: Serhey Popovych 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

net: fix compile error in skb_orphan_partial()

2017-09-15T17:29:43+00:00

commit 9142e9007f2d7ab58a587a1e1d921b0064a339aa upstream.

If CONFIG_INET is not set, net/core/sock.c can not compile :

net/core/sock.c: In function ‘skb_orphan_partial’:
net/core/sock.c:1810:2: error: implicit declaration of function
‘skb_is_tcp_pure_ack’ [-Werror=implicit-function-declaration]
  if (skb_is_tcp_pure_ack(skb))
  ^

Fix this by always including 

Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()")
Signed-off-by: Eric Dumazet 
Reported-by: Paul Gortmaker 
Reported-by: Randy Dunlap 
Reported-by: Stephen Rothwell 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings