linux-toradex.git/drivers/net, 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

mlx4_en: don't use napi_synchronize inside mlx4_en_netpoll

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

commit c98235cb8584a72e95786e17d695a8e5fafcd766 upstream.

The mlx4 driver is triggering schedules while atomic inside
mlx4_en_netpoll:

	spin_lock_irqsave(&cq->lock, flags);
	napi_synchronize(&cq->napi);
		^^^^^ msleep here
	mlx4_en_process_rx_cq(dev, cq, 0);
	spin_unlock_irqrestore(&cq->lock, flags);

This was part of a patch by Alexander Guller from Mellanox in 2011,
but it still isn't upstream.

Signed-off-by: Chris Mason 
Acked-By: Amir Vadai 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

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

xen-netback: remove pointless clause from if statement

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

[ Upstream commit 0576eddf24df716d8570ef8ca11452a9f98eaab2 ]

This patch removes a test in start_new_rx_buffer() that checks whether
a copy operation is less than MAX_BUFFER_OFFSET in length, since
MAX_BUFFER_OFFSET is defined to be PAGE_SIZE and the only caller of
start_new_rx_buffer() already limits copy operations to PAGE_SIZE or less.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Sander Eikelenboom 
Reported-By: Sander Eikelenboom 
Tested-By: Sander Eikelenboom 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: asix: add missing flag to struct driver_info

2014-04-09T01:20:46+00:00

commit d43ff4cd798911736fb39025ec8004284b1b0bc2 upstream.

The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.

Signed-off-by: Emil Goode 
Reported-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: asix: handle packets crossing URB boundaries

2014-04-09T01:20:45+00:00

commit 8b5b6f5413e97c3e8bafcdd67553d508f4f698cd upstream.

ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
header may now cross URB boundaries. To handle this we have to introduce
some state between individual calls to asix_rx_fixup().

Signed-off-by: Lucas Stach 
Signed-off-by: David S. Miller 
[ Emil: backported to 3.2:
 - dropped changes to drivers/net/usb/ax88172a.c 
 - Introduced some static function declarations as the functions
   are not used outside of asix.c (sparse is complaining about it) ]
Signed-off-by: Emil Goode 
Signed-off-by: Ben Hutchings

asix: asix_rx_fixup surgery to reduce skb truesizes

2014-04-09T01:20:45+00:00

commit a9e0aca4b37885b5599e52211f098bd7f565e749 upstream.

asix_rx_fixup() is complex, and does some unnecessary memory copies (at
least on x86 where NET_IP_ALIGN is 0)

Also, it tends to provide skbs with a big truesize (4096+256 with
MTU=1500) to upper stack, so incoming trafic consume a lot of memory and
I noticed early packet drops because we hit socket rcvbuf too fast.

Switch to a different strategy, using copybreak so that we provide nice
skbs to upper stack (including the NET_SKB_PAD to avoid future head
reallocations in some paths)

With this patch, I no longer see packets drops or tcp collapses on
various tcp workload with a AX88772 adapter.

Signed-off-by: Eric Dumazet 
Cc: Aurelien Jacobs 
Cc: Greg Kroah-Hartman 
Cc: Trond Wuellner 
Cc: Grant Grundler 
Cc: Paul Stewart 
Reviewed-by: Grant Grundler 
Reviewed-by: Grant Grundler 
Signed-off-by: David S. Miller 
[ Emil: Backported to 3.2: fixed small conflict ]
Signed-off-by: Emil Goode 
Signed-off-by: Ben Hutchings