linux-stable.git/net, branch v3.18.48

Fix "tunnels: Don't apply GRO to multiple layers of encapsulation."

2017-02-08T08:43:05+00:00

Commit dd4fff23f0f4c7c5414f50c091c78a7e423f85da which is commit
fac8e0f579695a3ecbc4d3cac369139d7f819971 upstream, seems to have
included the sit_gro_receive function, yet it never is used, causing an
obvious warning message.  Hook it up to the correct sit_offload
structure.

Note, for 3.16, the backport of fac8e0f579695a3ecbc4d3cac369139d7f819971
does not include this function, nor the ipip case.  I'm guessing that
this is not correct for 3.18, as one of the functions was included, but
could be totally wrong.

Cc: Jesse Gross 
Cc: David S. Miller 
Cc: Ben Hutchings 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net:Add sysctl_max_skb_frags

2017-02-08T08:43:05+00:00

commit 5f74f82ea34c0da80ea0b49192bb5ea06e063593 upstream.

Devices may have limits on the number of fragments in an skb they support.
Current codebase uses a constant as maximum for number of fragments one
skb can hold and use.
When enabling scatter/gather and running traffic with many small messages
the codebase uses the maximum number of fragments and may thereby violate
the max for certain devices.
The patch introduces a global variable as max number of fragments.

Signed-off-by: Hans Westgaard Ry 
Reviewed-by: Håkon Bugge 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter; Add some missing default cases to switch statements in nft_reject.

2017-02-08T08:43:04+00:00

commit 129d23a56623eea0947a05288158d76dc7f2f0ac upstream.

This fixes:

====================
net/netfilter/nft_reject.c: In function ‘nft_reject_dump’:
net/netfilter/nft_reject.c:61:2: warning: enumeration value ‘NFT_REJECT_TCP_RST’ not handled in switch [-Wswitch]
  switch (priv->type) {
  ^
net/netfilter/nft_reject.c:61:2: warning: enumeration value ‘NFT_REJECT_ICMPX_UNREACH’ not handled in switch [-Wswi\
tch]
net/netfilter/nft_reject_inet.c: In function ‘nft_reject_inet_dump’:
net/netfilter/nft_reject_inet.c:105:2: warning: enumeration value ‘NFT_REJECT_TCP_RST’ not handled in switch [-Wswi\
tch]
  switch (priv->type) {
  ^
====================

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

Bluetooth: make hci_test_bit's addr const

2017-02-08T08:43:03+00:00

commit 9391976a4da0d2a30abdb8d2704cfc7bf4bf9aab upstream.

gcc5 warns about passing a const array to hci_test_bit which takes a
non-const pointer:
net/bluetooth/hci_sock.c: In function ‘hci_sock_sendmsg’:
net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of ‘hci_test_bit’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]
        &hci_sec_filter.ocf_mask[ogf])) &&
        ^
net/bluetooth/hci_sock.c:49:19: note: expected ‘void *’ but argument is of type ‘const __u32 (*)[4] {aka const unsigned int (*)[4]}’
 static inline int hci_test_bit(int nr, void *addr)
                   ^

So make 'addr' 'const void *'.

Signed-off-by: Jiri Slaby 
Signed-off-by: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: Greg Kroah-Hartman

netfilter: Fix switch statement warnings with recent gcc.

2017-02-08T08:43:03+00:00

commit c1f866767777d1c6abae0ec57effffcb72017c00 upstream.

More recent GCC warns about two kinds of switch statement uses:

1) Switching on an enumeration, but not having an explicit case
   statement for all members of the enumeration.  To show the
   compiler this is intentional, we simply add a default case
   with nothing more than a break statement.

2) Switching on a boolean value.  I think this warning is dumb
   but nevertheless you get it wholesale with -Wswitch.

This patch cures all such warnings in netfilter.

Signed-off-by: David S. Miller 
Acked-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

net: caif: fix misleading indentation

2017-02-08T08:43:03+00:00

commit 8e0cc8c326d99e41468c96fea9785ab78883a281 upstream.

gcc points out code that is not indented the way it is
interpreted:

net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen':
net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
    return cfpkt_getlen(pkt);
    ^~~~~~
net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not
   else
   ^~~~

It is clear from the context that not returning here would be
a bug, as we'd end up passing a negative length into a function
that takes a u16 length, so it is not missing curly braces
here, and I'm assuming that the indentation is the only part
that's wrong about it.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

gro: Allow tunnel stacking in the case of FOU/GUE

2017-01-15T14:49:53+00:00

[ Upstream commit c3483384ee511ee2af40b4076366cd82a6a47b86 ]

This patch should fix the issues seen with a recent fix to prevent
tunnel-in-tunnel frames from being generated with GRO.  The fix itself is
correct for now as long as we do not add any devices that support
NETIF_F_GSO_GRE_CSUM.  When such a device is added it could have the
potential to mess things up due to the fact that the outer transport header
points to the outer UDP header and not the GRE header as would be expected.

Fixes: fac8e0f579695 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

tunnels: Don't apply GRO to multiple layers of encapsulation.

2017-01-15T14:49:53+00:00

[ Upstream commit fac8e0f579695a3ecbc4d3cac369139d7f819971 ]

When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.

No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.

UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.

Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: ipv4: Convert IP network timestamps to be y2038 safe

2017-01-15T14:49:53+00:00

[ Upstream commit 822c868532cae2cc1c51f4f18ab61c194d98aaf6 ]

ICMP timestamp messages and IP source route options require
timestamps to be in milliseconds modulo 24 hours from
midnight UT format.

Add inet_current_timestamp() function to support this. The function
returns the required timestamp in network byte order.

Timestamp calculation is also changed to call ktime_get_real_ts64()
which uses struct timespec64. struct timespec64 is y2038 safe.
Previously it called getnstimeofday() which uses struct timespec.
struct timespec is not y2038 safe.

Signed-off-by: Deepa Dinamani 
Cc: "David S. Miller" 
Cc: Alexey Kuznetsov 
Cc: Hideaki YOSHIFUJI 
Cc: James Morris 
Cc: Patrick McHardy 
Acked-by: YOSHIFUJI Hideaki 
Acked-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipip: Properly mark ipip GRO packets as encapsulated.

2017-01-15T14:49:53+00:00

[ Upstream commit b8cba75bdf6a48ea4811bbefb11a94a5c7281b68 ]

ipip encapsulated packets can be merged together by GRO but the result
does not have the proper GSO type set or even marked as being
encapsulated at all. Later retransmission of these packets will likely
fail if the device does not support ipip offloads. This is similar to
the issue resolved in IPv6 sit in feec0cb3
("ipv6: gro: support sit protocol").

Reported-by: Patrick Boutilier 
Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
Tested-by: Patrick Boutilier 
Acked-by: Eric Dumazet 
Signed-off-by: Jesse Gross 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin