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

rtlwifi: Fix fallback firmware loading

2017-09-09T15:39:28+00:00

commit 1d9b168d8ea9a0f51947d0e2f84856e77d2fe7ff upstream.

Commit f70e4df2b384 ("rtlwifi: Add code to read new versions of
firmware") added code to load an old firmware file if the new one is
not available.  Unfortunately that code is never reached because
request_firmware_nowait() does not wait for the firmware to show up
and returns 0 even if the file is not there.

Use the existing fallback mechanism introduced by commit 62009b7f1279
("rtlwifi: rtl8192cu: Add new firmware") instead.

Fixes: f70e4df2b384 ("rtlwifi: Add code to read new versions of firmware")
Signed-off-by: Sven Joachim 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Fix memory leak when firmware request fails

2017-09-09T15:39:28+00:00

commit f2764f61fa10593204b0c5e4e9a68dba02112e50 upstream.

This patch will fix memory leak when firmware request fails

Signed-off-by: Souptick Joarder 
Acked-by: Larry Finger 
Signed-off-by: Kalle Valo 
Cc: Sven Joachim 
Signed-off-by: Greg Kroah-Hartman

mwifiex: correct channel stat buffer overflows

2017-09-09T15:39:25+00:00

commit 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.

mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:

(a) scans can return info from more than one band (e.g., both 2.4 and 5
    GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
    channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
    (a) and (b) can easily lead to buffer overflows

Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.

Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw  survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.

(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)

Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex")
Cc: Avinash Patil 
Cc: Xinming Hu 
Signed-off-by: Brian Norris 
Reviewed-by: Dmitry Torokhov 
Reviewed-by: Ganapathi Bhat 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pci: add new PCI ID for 7265D

2017-09-09T15:39:25+00:00

commit 3f7a5e13e85026b6e460bbd6e87f87379421d272 upstream.

We have a new PCI subsystem ID for 7265D.  Add it to the list.

Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapter

2017-09-09T15:39:24+00:00

commit fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.

_rtl_pci_find_adapter fail path will jump to label fail3 for
unsupported adapter types.

However, on course for fail3 there will be call rtl_deinit_core
before rtl_init_core.

For the inclusion of checking pci_iounmap this fail can be moved to
fail2.

Fixes
[    4.492963] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]

Signed-off-by: Malcolm Priestley 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix memory leak in rx ring buffer allocation

2017-09-09T15:39:23+00:00

commit f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.

The rx ring buffers are added to a hash table if
firmware support full rx reorder. If the full rx
reorder support flag is not set before allocating
the rx ring buffers, none of the buffers are added
to the hash table.

There is a race condition between rx ring refill and
rx buffer replenish from napi poll. The interrupts are
enabled in hif start, before the rx ring is refilled during init.
We replenish buffers from napi poll due to the interrupts which
get enabled after hif start. Hence before the entire rx ring is
refilled during the init, the napi poll replenishes a few buffers
in steps of 100 buffers per attempt. During this rx ring replenish
from napi poll, the rx reorder flag has not been set due to which
the replenished buffers are not added to the hash table

Set the rx full reorder support flag before we allocate
the rx ring buffer to avoid the memory leak.

Signed-off-by: Rakesh Pillai 
Signed-off-by: Kalle Valo 
Cc: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

mlxsw: spectrum: Forbid linking to devices that have uppers

2017-09-01T16:59:41+00:00

The mlxsw driver relies on NETDEV_CHANGEUPPER events to configure the
device in case a port is enslaved to a master netdev such as bridge or
bond.

Since the driver ignores events unrelated to its ports and their
uppers, it's possible to engineer situations in which the device's data
path differs from the kernel's.

One example to such a situation is when a port is enslaved to a bond
that is already enslaved to a bridge. When the bond was enslaved the
driver ignored the event - as the bond wasn't one of its uppers - and
therefore a bridge port instance isn't created in the device.

Until such configurations are supported forbid them by checking that the
upper device doesn't have uppers of its own.

Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave")
Signed-off-by: Ido Schimmel 
Reported-by: Nogah Frankel 
Tested-by: Nogah Frankel 
Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller

wl1251: add a missing spin_lock_init()

2017-08-31T20:11:15+00:00

wl1251: add a missing spin_lock_init()

This fixes the following kernel warning:

 [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
 [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: /-1,
 .owner_cpu: 0
 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
 4.12.0-03002-gec979a4-dirty #40
 [ 5668.772796] Hardware name: Nokia RX-51 board
 [ 5668.773071] Workqueue: phy1 wl1251_irq_work
 [ 5668.773345] [] (unwind_backtrace) from []
 (show_stack+0x10/0x14)
 [ 5668.773803] [] (show_stack) from []
 (do_raw_spin_lock+0x6c/0xa0)
 [ 5668.774230] [] (do_raw_spin_lock) from []
 (_raw_spin_lock_irqsave+0x10/0x18)
 [ 5668.774658] [] (_raw_spin_lock_irqsave) from []
 (wl1251_op_tx+0x38/0x5c)
 [ 5668.775115] [] (wl1251_op_tx) from []
 (ieee80211_tx_frags+0x188/0x1c0)
 [ 5668.775543] [] (ieee80211_tx_frags) from []
 (__ieee80211_tx+0x6c/0x130)
 [ 5668.775970] [] (__ieee80211_tx) from []
 (ieee80211_tx+0xdc/0x104)
 [ 5668.776367] [] (ieee80211_tx) from []
 (__ieee80211_subif_start_xmit+0x454/0x8c8)
 [ 5668.776824] [] (__ieee80211_subif_start_xmit) from
 [] (ieee80211_subif_start_xmit+0x30/0x2fc)
 [ 5668.777343] [] (ieee80211_subif_start_xmit) from
 [] (dev_hard_start_xmit+0x80/0x118)
...

    by adding the missing spin_lock_init().

Reported-by: Pavel Machek 
Cc: Kalle Valo 
Signed-off-by: Cong Wang 
Acked-by: Pavel Machek 
Signed-off-by: Kalle Valo 
Signed-off-by: Pavel Machek 
Cc: stable@kernel.org
Signed-off-by: David S. Miller

Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

2017-08-31T01:47:25+00:00

This reverts commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ("net: phy:
Correctly process PHY_HALTED in phy_stop_machine()") because it is
creating the possibility for a NULL pointer dereference.

David Daney provide the following call trace and diagram of events:

When ndo_stop() is called we call:

 phy_disconnect()
    +---> phy_stop_interrupts() implies: phydev->irq = PHY_POLL;
    +---> phy_stop_machine()
    |      +---> phy_state_machine()
    |              +----> queue_delayed_work(): Work queued.
    +--->phy_detach() implies: phydev->attached_dev = NULL;

Now at a later time the queued work does:

 phy_state_machine()
    +---->netif_carrier_off(phydev->attached_dev): Oh no! It is NULL:

 CPU 12 Unable to handle kernel paging request at virtual address
0000000000000048, epc == ffffffff80de37ec, ra == ffffffff80c7c
Oops[#1]:
CPU: 12 PID: 1502 Comm: kworker/12:1 Not tainted 4.9.43-Cavium-Octeon+ #1
Workqueue: events_power_efficient phy_state_machine
task: 80000004021ed100 task.stack: 8000000409d70000
$ 0   : 0000000000000000 ffffffff84720060 0000000000000048 0000000000000004
$ 4   : 0000000000000000 0000000000000001 0000000000000004 0000000000000000
$ 8   : 0000000000000000 0000000000000000 00000000ffff98f3 0000000000000000
$12   : 8000000409d73fe0 0000000000009c00 ffffffff846547c8 000000000000af3b
$16   : 80000004096bab68 80000004096babd0 0000000000000000 80000004096ba800
$20   : 0000000000000000 0000000000000000 ffffffff81090000 0000000000000008
$24   : 0000000000000061 ffffffff808637b0
$28   : 8000000409d70000 8000000409d73cf0 80000000271bd300 ffffffff80c7804c
Hi    : 000000000000002a
Lo    : 000000000000003f
epc   : ffffffff80de37ec netif_carrier_off+0xc/0x58
ra    : ffffffff80c7804c phy_state_machine+0x48c/0x4f8
Status: 14009ce3        KX SX UX KERNEL EXL IE
Cause : 00800008 (ExcCode 02)
BadVA : 0000000000000048
PrId  : 000d9501 (Cavium Octeon III)
Modules linked in:
Process kworker/12:1 (pid: 1502, threadinfo=8000000409d70000,
task=80000004021ed100, tls=0000000000000000)
Stack : 8000000409a54000 80000004096bab68 80000000271bd300 80000000271c1e00
        0000000000000000 ffffffff808a1708 8000000409a54000 80000000271bd300
        80000000271bd320 8000000409a54030 ffffffff80ff0f00 0000000000000001
        ffffffff81090000 ffffffff808a1ac0 8000000402182080 ffffffff84650000
        8000000402182080 ffffffff84650000 ffffffff80ff0000 8000000409a54000
        ffffffff808a1970 0000000000000000 80000004099e8000 8000000402099240
        0000000000000000 ffffffff808a8598 0000000000000000 8000000408eeeb00
        8000000409a54000 00000000810a1d00 0000000000000000 8000000409d73de8
        8000000409d73de8 0000000000000088 000000000c009c00 8000000409d73e08
        8000000409d73e08 8000000402182080 ffffffff808a84d0 8000000402182080
        ...
Call Trace:
[] netif_carrier_off+0xc/0x58
[] phy_state_machine+0x48c/0x4f8
[] process_one_work+0x158/0x368
[] worker_thread+0x150/0x4c0
[] kthread+0xc8/0xe0
[] ret_from_kernel_thread+0x14/0x1c

The original motivation for this change originated from Marc Gonzales
indicating that his network driver did not have its adjust_link callback
executing with phydev->link = 0 while he was expecting it.

PHYLIB has never made any such guarantees ever because phy_stop() merely just
tells the workqueue to move into PHY_HALTED state which will happen
asynchronously.

Reported-by: Geert Uytterhoeven 
Reported-by: David Daney 
Fixes: 7ad813f20853 ("net: phy: Correctly process PHY_HALTED in phy_stop_machine()")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller

Merge tag 'mlx5-fixes-2017-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux

2017-08-30T23:39:01+00:00

Saeed Mahameed says:

====================
Mellanox, mlx5 fixes 2017-08-30

This series contains some misc fixes to the mlx5 driver.

Please pull and let me know if there's any problem.

For -stable:

Kernels >= 4.12
	net/mlx5e: Fix CQ moderation mode not set properly
	net/mlx5e: Don't override user RSS upon set channels

Kernels >= 4.11
	net/mlx5e: Properly resolve TC offloaded ipv6 vxlan tunnel source address

Kernels >= 4.10
	net/mlx5e: Fix DCB_CAP_ATTR_DCBX capability for DCBNL getcap
	net/mlx5e: Check for qos capability in dcbnl_initialize

Kernels >= 4.9
	net/mlx5e: Fix dangling page pointer on DMA mapping error

Kernels >= 4.8
	net/mlx5e: Fix inline header size for small packets
	net/mlx5: E-Switch, Unload the representors in the correct order
    	net/mlx5: Fix arm SRQ command for ISSI version 0
====================

Signed-off-by: David S. Miller