linux-toradex.git/net, branch v3.18.12

Revert "libceph: use memalloc flags for net IO"

2015-04-17T00:13:14+00:00

[ Upstream commit 6d7fdb0ab351b33d4c12d53fe44be030b90fc9d4 ]

This reverts commit 89baaa570ab0b476db09408d209578cfed700e9f.

Dirty page throttling should be sufficient for us in the general case
so there is no need to use __GFP_MEMALLOC - it would be needed only in
the swap-over-rbd case, which we currently don't support.  (It would
probably take approximately the commit that is being reverted to add
that support, but we would also need the "swap" option to distinguish
from the general case and make sure swap ceph_client-s aren't shared
with anything else.)  See ceph-devel threads [1] and [2] for the
details of why enabling pfmemalloc reserves for all cases is a bad
thing.

On top of potential system lockups related to drained emergency
reserves, this turned out to cause ceph lockups in case peers are on
the same host and communicating via loopback due to sk_filter()
dropping pfmemalloc skbs on the receiving side because the receiving
loopback socket is not tagged with SOCK_MEMALLOC.

[1] "SOCK_MEMALLOC vs loopback"
    http://www.spinics.net/lists/ceph-devel/msg22998.html
[2] "[PATCH] libceph: don't set memalloc flags in loopback case"
    http://www.spinics.net/lists/ceph-devel/msg23392.html

Conflicts:
	net/ceph/messenger.c [ context: tcp_nodelay option ]

Cc: Mike Christie 
Cc: Mel Gorman 
Cc: Sage Weil 
Cc: stable@vger.kernel.org # 3.18+, needs backporting
Signed-off-by: Ilya Dryomov 
Acked-by: Mike Christie 
Acked-by: Mel Gorman 
[idryomov@gmail.com: backport to 3.18, 3.19: context]
Signed-off-by: Sasha Levin

mac80211: count interfaces correctly for combination checks

2015-04-17T00:11:38+00:00

[ Upstream commit 0f611d28fc2e13cfec64e1c544c16a086886805a ]

Since moving the interface combination checks to mac80211, it's
broken because it now only considers interfaces with an assigned
channel context, so for example any interface that isn't active
can still be up, which is clearly an issue; also, in particular
P2P-Device wdevs are an issue since they never have a chanctx.

Fix this by counting running interfaces instead the ones with a
channel context assigned.

Cc: stable@vger.kernel.org [3.16+]
Fixes: 73de86a38962b ("cfg80211/mac80211: move interface counting for combination check to mac80211")
Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Emmanuel Grumbach 
[rewrite commit message, dig out the commit it fixes]
Signed-off-by: Johannes Berg 

Signed-off-by: Sasha Levin

mac80211: drop unencrypted frames in mesh fwding

2015-04-17T00:11:37+00:00

[ Upstream commit d0c22119f574b851e63360c6b8660fe9593bbc3c ]

The mesh forwarding path was not checking that data
frames were protected when running an encrypted network;
add the necessary check.

Cc: stable@vger.kernel.org
Reported-by: Johannes Berg 
Signed-off-by: Bob Copeland 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: disable u-APSD queues by default

2015-04-17T00:11:37+00:00

[ Upstream commit aa75ebc275b2a91b193654a177daf900ad6703f0 ]

Some APs experience problems when working with
U-APSD. Decreasing the probability of that
happening by using legacy mode for all ACs but VO
isn't enough.

Cisco 4410N originally forced us to enable VO by
default only because it treated non-VO ACs as
legacy.

However some APs (notably Netgear R7000) silently
reclassify packets to different ACs. Since u-APSD
ACs require trigger frames for frame retrieval
clients would never see some frames (e.g. ARP
responses) or would fetch them accidentally after
a long time.

It makes little sense to enable u-APSD queues by
default because it needs userspace applications to
be aware of it to actually take advantage of the
possible additional powersavings. Implicitly
depending on driver autotrigger frame support
doesn't make much sense.

Cc: stable@vger.kernel.org
Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

nl80211: ignore HT/VHT capabilities without QoS/WMM

2015-04-17T00:11:36+00:00

[ Upstream commit 496fcc294daab18799e190c0264863d653588d1f ]

As HT/VHT depend heavily on QoS/WMM, it's not a good idea to
let userspace add clients that have HT/VHT but not QoS/WMM.
Since it does so in certain cases we've observed (client is
using HT IEs but not QoS/WMM) just ignore the HT/VHT info at
this point and don't pass it down to the drivers which might
unconditionally use it.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

can: add missing initialisations in CAN related skbuffs

2015-03-28T13:37:33+00:00

[ Upstream commit 969439016d2cf61fef53a973d7e6d2061c3793b1 ]

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh 
Reported-by: Daniel Steer 
Signed-off-by: Oliver Hartkopp 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

tcp: make connect() mem charging friendly

2015-03-24T12:22:22+00:00

[ Upstream commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ]

While working on sk_forward_alloc problems reported by Denys
Fedoryshchenko, we found that tcp connect() (and fastopen) do not call
sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so
sk_forward_alloc is negative while connect is in progress.

We can fix this by calling regular sk_stream_alloc_skb() both for the
SYN packet (in tcp_connect()) and the syn_data packet in
tcp_send_syn_data()

Then, tcp_send_syn_data() can avoid copying syn_data as we simply
can manipulate syn_data->cb[] to remove SYN flag (and increment seq)

Instead of open coding memcpy_fromiovecend(), simply use this helper.

This leaves in socket write queue clean fast clone skbs.

This was tested against our fastopen packetdrill tests.

Reported-by: Denys Fedoryshchenko 
Signed-off-by: Eric Dumazet 
Acked-by: Yuchung Cheng 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour

2015-03-24T12:22:21+00:00

[ Upstream commit 91edd096e224941131f896b86838b1e59553696a ]

Commit db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an
error) introduced the clamping of msg_namelen when the unsigned value
was larger than sizeof(struct sockaddr_storage). This caused a
msg_namelen of -1 to be valid. The native code was subsequently fixed by
commit dbb490b96584 (net: socket: error on a negative msg_namelen).

In addition, the native code sets msg_namelen to 0 when msg_name is
NULL. This was done in commit (6a2a2b3ae075 net:socket: set msg_namelen
to 0 if msg_name is passed as NULL in msghdr struct from userland) and
subsequently updated by 08adb7dabd48 (fold verify_iovec() into
copy_msghdr_from_user()).

This patch brings the get_compat_msghdr() in line with
copy_msghdr_from_user().

Fixes: db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error)
Cc: David S. Miller 
Cc: Dan Carpenter 
Signed-off-by: Catalin Marinas 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

tcp: fix tcp fin memory accounting

2015-03-24T12:22:21+00:00

[ Upstream commit d22e1537181188e5dc8cbc51451832625035bdc2 ]

tcp_send_fin() does not account for the memory it allocates properly, so
sk_forward_alloc can be negative in cases where we've sent a FIN:

ss example output (ss -amn | grep -B1 f4294):
tcp    FIN-WAIT-1 0      1            192.168.0.1:45520         192.0.2.1:8080
	skmem:(r0,rb87380,t0,tb87380,f4294966016,w1280,o0,bl0)
Acked-by: Eric Dumazet 

Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipv6: fix backtracking for throw routes

2015-03-24T12:22:21+00:00

[ Upstream commit 73ba57bfae4a1914f6a6dac71e3168dd900e00af ]

for throw routes to trigger evaluation of other policy rules
EAGAIN needs to be propagated up to fib_rules_lookup
similar to how its done for IPv4

A simple testcase for verification is:

ip -6 rule add lookup 33333 priority 33333
ip -6 route add throw 2001:db8::1
ip -6 route add 2001:db8::1 via fe80::1 dev wlan0 table 33333
ip route get 2001:db8::1

Signed-off-by: Steven Barth 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin