linux-stable.git/drivers/net/wireless, branch v3.2.59

rtl8192ce: Fix null dereference in watchdog

2014-05-18T13:58:09+00:00

Dmitry Semyonov reported that after upgrading from 3.2.54 to
3.2.57 the rtl8192ce driver will crash when its interface is brought
up.  The oops message shows:

[ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 1833.611455] IP: [] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce]
...
[ 1833.613326] Call Trace:
[ 1833.613346]  [] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common]
[ 1833.613391]  [] ? process_one_work+0x161/0x269
[ 1833.613425]  [] ? worker_thread+0xc2/0x145
[ 1833.613458]  [] ? manage_workers.isra.25+0x15b/0x15b
[ 1833.613496]  [] ? kthread+0x76/0x7e
[ 1833.613527]  [] ? kernel_thread_helper+0x4/0x10
[ 1833.613563]  [] ? kthread_worker_fn+0x139/0x139
[ 1833.613598]  [] ? gs_change+0x13/0x13

Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta'
parameter was null.  None of the changes to the rtlwifi family between
3.2.54 and 3.2.57 seem to directly cause this, and reverting commit 
f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs')
doesn't fix it.

rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via
rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the
call trace as it was inlined.  That function has been completely
removed upstream which may explain why this crash wasn't seen there.

I'm not sure that it is sensible to completely remove
rtl92c_dm_refresh_rate_adaptive_mask() without making other
compensating changes elsewhere, so try to work around this for 3.2 by
checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask()
and then skipping the call to rtl92ce_update_hal_rate_tbl().

References: https://bugs.debian.org/745137
References: https://bugs.debian.org/745462
Reported-by: Dmitry Semyonov 
Signed-off-by: Ben Hutchings 
Cc: Larry Finger 
Cc: Chaoming Li

b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR

2014-04-30T15:23:26+00:00

commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream.

Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
functions isn't safe. On my machine it causes delayed (!) CPU exception:

Disabling lock debugging due to kernel taint
mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
mce: [Hardware Error]: TSC 164083803dc
mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
mce: [Hardware Error]: Run the above through 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Processor context corrupt
Kernel panic - not syncing: Fatal machine check on current CPU
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

Signed-off-by: Rafał Miłecki 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: fix ready time of the multicast buffer queue

2014-04-30T15:23:22+00:00

commit 3b3e0efb5c72c4fc940af50b33626b8a78a907dc upstream.

qi->tqi_readyTime is written directly to registers that expect
microseconds as unit instead of TU.
When setting the CABQ ready time, cur_conf->beacon_interval is in TU, so
convert it to microseconds before passing it to ath9k_hw.

This should hopefully fix some Tx DMA issues with buffered multicast
frames in AP mode.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

iwlwifi: dvm: take mutex when sending SYNC BT config command

2014-04-30T15:23:21+00:00

commit 82e5a649453a3cf23516277abb84273768a1592b upstream.

There is a flow in which we send the host command in SYNC
mode, but we don't take priv->mutex.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495

Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
[bwh: Backported to 3.2:
 - Adjust filename, context
 - mutex is priv->shrd->mutex]
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192se: Fix too long disable of IRQs

2014-04-30T15:23:21+00:00

commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.

In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
 fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192se.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change to an error path that we don't have]
Signed-off-by: Ben Hutchings

mwifiex: copy AP's HT capability info correctly

2014-04-01T23:58:58+00:00

commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream.

While preparing association request, intersection of device's HT
capability information and corresponding fields advertised by AP
is used.

This patch fixes an error while copying this field from AP's
beacon.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

iwlwifi: fix TX status for aggregated packets

2014-04-01T23:58:56+00:00

commit 143582c6847cb285b361804c613127c25de60ca4 upstream.

Only the first packet is currently handled correctly, but then
all others are assumed to have failed which is problematic. Fix
this, marking them all successful instead (since if they're not
then the firmware will have transmitted them as single frames.)

This fixes the lost packet reporting.

Also do a tiny variable scoping cleanup.

Signed-off-by: Johannes Berg 
[Add the dvm part]
Signed-off-by: Emmanuel Grumbach 
[bwh: Backported to 3.2:
 - Drop the mvm part
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

ath9k: Fix ETSI compliance for AR9462 2.0

2014-04-01T23:58:55+00:00

commit b3050248c167871ca52cfdb2ce78aa2460249346 upstream.

The minimum CCA power threshold values have to be adjusted
for existing cards to be in compliance with new regulations.
Newer cards will make use of the values obtained from EEPROM,
support for this was added earlier. To make sure that cards
that are already in use and don't have proper values in EEPROM,
do not violate regulations, use the initvals instead.

Reported-by: Jeang Daniel 
Signed-off-by: Sujith Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: protect tid->sched check

2014-04-01T23:58:55+00:00

commit 21f8aaee0c62708654988ce092838aa7df4d25d8 upstream.

We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That
is race condition which can result of doing list_del(&tid->list) twice
(second time with poisoned list node) and cause crash like shown below:

[424271.637220] BUG: unable to handle kernel paging request at 00100104
[424271.637328] IP: [] ath_tx_aggr_sleep+0x62/0xe0 [ath9k]
...
[424271.639953] Call Trace:
[424271.639998]  [] ? ath9k_get_survey+0x110/0x110 [ath9k]
[424271.640083]  [] ath9k_sta_notify+0x42/0x50 [ath9k]
[424271.640177]  [] sta_ps_start+0x8f/0x1c0 [mac80211]
[424271.640258]  [] ? free_compound_page+0x2e/0x40
[424271.640346]  [] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211]
[424271.640437]  [] ? kmem_cache_free+0x1d8/0x1f0
[424271.640510]  [] ? kfree_skbmem+0x34/0x90
[424271.640578]  [] ? put_page+0x2c/0x40
[424271.640640]  [] ? kfree_skbmem+0x34/0x90
[424271.640706]  [] ? kfree_skbmem+0x34/0x90
[424271.640787]  [] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211]
[424271.640897]  [] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211]
[424271.641009]  [] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211]
[424271.641104]  [] ? ip_output+0x7e/0xd0
[424271.641182]  [] ieee80211_rx+0x307/0x7c0 [mac80211]
[424271.641266]  [] ath_rx_tasklet+0x88e/0xf70 [ath9k]
[424271.641358]  [] ? ieee80211_rx+0x1dc/0x7c0 [mac80211]
[424271.641445]  [] ath9k_tasklet+0xcb/0x130 [ath9k]

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=70551

Reported-and-tested-by: Max Sydorenko 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2:
 - Adjust context
 - Use spin_unlock_bh() directly]
Signed-off-by: Ben Hutchings

rtl8187: fix regression on MIPS without coherent DMA

2014-04-01T23:58:52+00:00

commit b6213e413a4e0c66548153516b074df14f9d08e0 upstream.

This patch fixes regression caused by commit a16dad77634 "MIPS: Fix
potencial corruption". That commit fixes one corruption scenario in
cost of adding another one, which actually start to cause crashes
on Yeeloong laptop when rtl8187 driver is used.

For correct DMA read operation on machines without DMA coherence, kernel
have to invalidate cache, such it will refill later with new data that
device wrote to memory, when that data is needed to process. We can only
invalidate full cache line. Hence when cache line includes both dma
buffer and some other data (written in cache, but not yet in main
memory), the other data can not hit memory due to invalidation. That
happen on rtl8187 where struct rtl8187_priv fields are located just
before and after small buffers that are passed to USB layer and DMA
is performed on them.

To fix the problem we align buffers and reserve space after them to make
them match cache line.

This patch does not resolve all possible MIPS problems entirely, for
that we have to assure that we always map cache aligned buffers for DMA,
what can be complex or even not possible. But patch fixes visible and
reproducible regression and seems other possible corruptions do not
happen in practice, since Yeeloong laptop works stable without rtl8187
driver.

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=54391

Reported-by: Petr Pisar 
Bisected-by: Tom Li 
Reported-and-tested-by: Tom Li 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Larry Finger 
Acked-by: Hin-Tak Leung 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings