linux-stable.git/drivers/net, branch v4.6.5

cdc_ncm: workaround for EM7455 "silent" data interface

2016-07-27T15:42:14+00:00

[ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ]

Several Lenovo users have reported problems with their Sierra
Wireless EM7455 modem. The driver has loaded successfully and
the MBIM management channel has appeared to work, including
establishing a connection to the mobile network. But no frames
have been received over the data interface.

The problem affects all EM7455 and MC7455, and is assumed to
affect other modems based on the same Qualcomm chipset and
baseband firmware.

Testing narrowed the problem down to what seems to be a
firmware timing bug during initialization. Adding a short sleep
while probing is sufficient to make the problem disappear.
Experiments have shown that 1-2 ms is too little to have any
effect, while 10-20 ms is enough to reliably succeed.

Reported-by: Stefan Armbruster 
Reported-by: Ralph Plawetzki 
Reported-by: Andreas Fett 
Reported-by: Rasmus Lerdorf 
Reported-by: Samo Ratnik 
Reported-and-tested-by: Aleksander Morgado 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

geneve: fix max_mtu setting

2016-07-27T15:42:13+00:00

[ Upstream commit d5d5e8d55732c7c35c354e45e3b0af2795978a57 ]

For ipv6+udp+geneve encapsulation data, the max_mtu should subtract
sizeof(ipv6hdr), instead of sizeof(iphdr).

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

macsec: set actual real device for xmit when !protect_frames

2016-07-27T15:42:13+00:00

[ Upstream commit 79c62220d74a4a3f961a2cb7320da09eebf5daf7 ]

Avoid recursions of dev_queue_xmit() to the wrong net device when
frames are unprotected, since at that time skb->dev still points to
our own macsec dev and unlike macsec_encrypt_finish() dev pointer
doesn't get updated to real underlying device.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Daniel Borkmann 
Acked-by: Sabrina Dubroca 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01

2016-07-27T15:42:11+00:00

commit de26859dcf363d520cc44e59f6dcaf20ebe0aadf upstream.

Commit 49f86ec21c01 ("rtlwifi: Change long delays to sleeps") was correct
for most cases; however, driver rtl8192ce calls the affected routines while
in atomic context. The kernel bug output is as follows:

BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
[...]
  [] __schedule+0x899/0xad0
  [] schedule+0x3c/0x90
  [] schedule_hrtimeout_range_clock+0xa2/0x120
  [] ? hrtimer_init+0x120/0x120
  [] ? schedule_hrtimeout_range_clock+0x96/0x120
  [] schedule_hrtimeout_range+0x13/0x20
  [] usleep_range+0x4f/0x70
  [] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
  [] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]

To fix this bug, three of the changes from delay to sleep are reverted.
Unfortunately, one of the changes involves a delay of 50 msec. The calling
code will be modified so that this long delay can be avoided; however,
this change is being pushed now to fix the problem in kernel 4.6.0.

Fixes: 49f86ec21c01 ("rtlwifi: Change long delays to sleeps")
Reported-by: James Feeney 
Signed-off-by: Larry Finger 
Cc: James Feeney 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL

2016-07-27T15:42:07+00:00

commit 62397da50bb20a6b812c949ef465d7e69fe54bb6 upstream.

A wmediumd that does not send this attribute causes a NULL pointer
dereference, as the attribute is accessed even if it does not exist.

The attribute was required but never checked ever since userspace frame
forwarding has been introduced. The issue gets more problematic once we
allow wmediumd registration from user namespaces.

Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx")
Signed-off-by: Martin Willi 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

net: nps_enet: Disable interrupts before napi reschedule

2016-06-24T17:22:01+00:00

[ Upstream commit 86651650d16a359e4142c6a8b0467c87e48c4c94 ]

Since NAPI works by shutting down event interrupts when theres
work and turning them on when theres none, the net driver must
make sure that interrupts are disabled when it reschedules polling.
By calling napi_reschedule, the driver switches to polling mode,
therefor there should be no interrupt interference.
Any received packets will be handled in nps_enet_poll by polling the HW
indication of received packet until all packets are handled.

Signed-off-by: Elad Kanfi 
Acked-by: Noam Camus 
Tested-by: Alexey Brodkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vxlan: Accept user specified MTU value when create new vxlan link

2016-06-24T17:22:00+00:00

[ Upstream commit ce577668a426c6a9e2470a09dcd07fbd6e45272a ]

When create a new vxlan link, example:
  ip link add vtap mtu 1440 type vxlan vni 1 dev eth0

The argument "mtu" has no effect, because it is not set to conf->mtu. The
default value is used in vxlan_dev_configure function.

This problem was introduced by commit 0dfbdf4102b9 (vxlan: Factor out device
configuration).

Fixes: 0dfbdf4102b9 (vxlan: Factor out device configuration)
Signed-off-by:  Chen Haiquan 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: stmmac: Fix incorrect memcpy source memory

2016-06-24T17:22:00+00:00

[ Upstream commit 643d60bf575daaba93c1ac0d0e1c4b1d4ded1f75 ]

The memcpy() currently copies mdio_bus_data into new_bus->irq, which
makes no sense, since the mdio_bus_data structure contains more than
just irqs. The code was likely supposed to copy mdio_bus_data->irqs
into the new_bus->irq instead, so fix this.

Fixes: e7f4dc3536a4 ("mdio: Move allocation of interrupts into core")
Signed-off-by: Marek Vasut 
Cc: David S. Miller 
Cc: Giuseppe Cavallaro 
Cc: Alexandre Torgue 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: alx: use custom skb allocator

2016-06-24T17:22:00+00:00

[ Upstream commit 26c5f03b2ae8018418ceb25b2e6a48560e8c2f5b ]

This patch follows Eric Dumazet's commit 7b70176421 for Atheros
atl1c driver to fix one exactly same bug in alx driver, that the
network link will be lost in 1-5 minutes after the device is up.

My laptop Lenovo Y580 with Atheros AR8161 ethernet device hit the
same problem with kernel 4.4, and it will be cured by Jarod Wilson's
commit c406700c for alx driver which get merged in 4.5. But there
are still some alx devices can't function well even with Jarod's
patch, while this patch could make them work fine. More details on
	https://bugzilla.kernel.org/show_bug.cgi?id=70761

The debug shows the issue is very likely to be related with the RX
DMA address, specifically 0x...f80, if RX buffer get 0x...f80 several
times, their will be RX overflow error and device will stop working.

For kernel 4.5.0 with Jarod's patch which works fine with my
AR8161/Lennov Y580, if I made some change to the
	__netdev_alloc_skb
		--> __alloc_page_frag()
to make the allocated buffer can get an address with 0x...f80,
then the same error happens. If I make it to 0x...f40 or 0x....fc0,
everything will be still fine. So I tend to believe that the
0x..f80 address cause the silicon to behave abnormally.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70761
Cc: Eric Dumazet 
Cc: Johannes Berg 
Cc: Jarod Wilson 
Signed-off-by: Feng Tang 
Tested-by: Ole Lukoie 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

team: don't call netdev_change_features under team->lock

2016-06-24T17:22:00+00:00

[ Upstream commit f6988cb63a4e698d8a62a1d085d263d1fcc351ea ]

The team_device_event() notifier calls team_compute_features() to fix
vlan_features under team->lock to protect team->port_list. The problem is
that subsequent __team_compute_features() calls netdev_change_features()
to propagate vlan_features to upper vlan devices while team->lock is still
taken. This can lead to deadlock when NETIF_F_LRO is modified on lower
devices or team device itself.

Example:
The team0 as active backup with eth0 and eth1 NICs. Both eth0 & eth1 are
LRO capable and LRO is enabled. Thus LRO is also enabled on team0.

The command 'ethtool -K team0 lro off' now hangs due to this deadlock:

dev_ethtool()
-> ethtool_set_features()
 -> __netdev_update_features(team)
  -> netdev_sync_lower_features()
   -> netdev_update_features(lower_1)
    -> __netdev_update_features(lower_1)
    -> netdev_features_change(lower_1)
     -> call_netdevice_notifiers(...)
      -> team_device_event(lower_1)
       -> team_compute_features(team) [TAKES team->lock]
        -> netdev_change_features(team)
         -> __netdev_update_features(team)
          -> netdev_sync_lower_features()
           -> netdev_update_features(lower_2)
            -> __netdev_update_features(lower_2)
            -> netdev_features_change(lower_2)
             -> call_netdevice_notifiers(...)
              -> team_device_event(lower_2)
               -> team_compute_features(team) [DEADLOCK]

The bug is present in team from the beginning but it appeared after the commit
fd867d5 (net/core: generic support for disabling netdev features down stack)
that adds synchronization of features with lower devices.

Fixes: fd867d5 (net/core: generic support for disabling netdev features down stack)
Cc: Jiri Pirko 
Signed-off-by: Ivan Vecera 
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman