linux-stable.git/drivers/net, branch v3.8.2

b43: Fix lockdep splat on module unload

2013-03-03T22:03:33+00:00

commit 63a02ce1c5c59baa40b99756492e3ec8d6b51483 upstream.

On unload, b43 produces a lockdep warning that can be summarized in the
following way:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.8.0-wl+ #117 Not tainted
 -------------------------------------------------------
 modprobe/5557 is trying to acquire lock:
  ((&wl->firmware_load)){+.+.+.}, at: [] flush_work+0x0/0x2a0

 but task is already holding lock:
  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20

 which lock already depends on the new lock.
 [ INFO: possible circular locking dependency detected ]
 ======================================================

The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html.
To summarize, commit 6b6fa58 added a 'cancel_work_sync(&wl->firmware_load)'
call in the wrong place.

The fix is to move the cancel_work_sync() call to b43_bcma_remove() and
b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in
diagnosing the log output.

Signed-off-by: Larry Finger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlx4_en: fix allocation of CPU affinity reverse-map

2013-02-28T13:38:41+00:00

[ Upstream commit 3770699675dd1b8fc1e86ff369eb3cce44e10082 ]

The mlx4_en driver allocates the number of objects for the CPU affinity
reverse-map based on the number of rx rings of the device. However,
mlx4_assign_eq() calls irq_cpu_rmap_add() as many times as IRQ's are
assigned to EQ's, which can be as large as mlx4_dev->caps.comp_pool. If
caps.comp_pool is larger than rx_ring_num we will eventually hit the
BUG_ON() in cpu_rmap_add().

Fix this problem by allocating space for the maximum number of CPU
affinity reverse-map objects we might want to add.

Signed-off-by: Kleber Sacilotto de Souza 
Acked-by: Amir Vadai 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlx4_en: fix allocation of device tx_cq

2013-02-28T13:38:41+00:00

[ Upstream commit 427a96252d8eee7b9bbafce15bd37fa3387ede55 ]

The memory to hold the network device tx_cq is not being allocated with
the correct size in mlx4_en_init_netdev(). It should use MAX_TX_RINGS
instead of MAX_RX_RINGS. This can cause problems if the number of tx
rings being used is greater than MAX_RX_RINGS.

Signed-off-by: Kleber Sacilotto de Souza 
Acked-by: Amir Vadai 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ppp: set qdisc_tx_busylock to avoid LOCKDEP splat

2013-02-28T13:38:40+00:00

[ Upstream commit 303c07db487be59ae9fda10600ea65ca11c21497 ]

If a qdisc is installed on a ppp device, its possible to get
a lockdep splat under stress, because nested dev_queue_xmit() can
lock busylock a second time (on a different device, so its a false
positive)

Avoid this problem using a distinct lock_class_key for ppp
devices.

Reported-by: Yanko Kaneti 
Tested-by: Yanko Kaneti 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen-netback: cancel the credit timer when taking the vif down

2013-02-28T13:38:40+00:00

[ Upstream commit 3e55f8b306cf305832a4ac78aa82e1b40e818ece ]

If the credit timer is left armed after calling
xen_netbk_remove_xenvif(), then it may fire and attempt to schedule
the vif which will then oops as vif->netbk == NULL.

This may happen both in the fatal error path and during normal
disconnection from the front end.

The sequencing during shutdown is critical to ensure that: a)
vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif
is not freed.

1. Mark as unschedulable (netif_carrier_off()).
2. Synchronously cancel the timer.
3. Remove the vif from the schedule list.
4. Remove it from it netback thread group.
5. Wait for vif->refcnt to become 0.

Signed-off-by: David Vrabel 
Acked-by: Ian Campbell 
Reported-by: Christopher S. Aker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen-netback: correctly return errors from netbk_count_requests()

2013-02-28T13:38:40+00:00

[ Upstream commit 35876b5ffc154c357476b2c3bdab10feaf4bd8f0 ]

netbk_count_requests() could detect an error, call
netbk_fatal_tx_error() but return 0.  The vif may then be used
afterwards (e.g., in a call to netbk_tx_error().

Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may
be freed immediately after the call to netbk_fatal_tx_error() (e.g.,
if the vif is also removed).

Netback thread              Xenwatch thread
-------------------------------------------
netbk_fatal_tx_err()        netback_remove()
                              xenvif_disconnect()
                                ...
                                free_netdev()
netbk_tx_err() Oops!

Signed-off-by: Wei Liu 
Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Reported-by: Christopher S. Aker 
Acked-by: Ian Campbell 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: cdc_ncm: fix probing of devices with multiple control interface altsettings

2013-02-28T13:38:40+00:00

[ Upstream commit f350ca03703133c94fe742f6fa6ff0fd8f5a9a09 ]

commit bd329e1 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
added a test for a CDC MBIM altsetting, implementing the cdc_ncm part of
MBIM backward compatibility support.  This intentionally made the driver
behave differently for CDC NCM devices with 2 alternate settings for the
Communication interface, depending on whether or not CONFIG_USB_NET_CDC_MBIM
was enabled.  This is correct iff alternate setting #1 really *is* a MBIM
setting.  If not, then NCM probing will use a different altsetting than before,
possibly causing probing failures depending on CONFIG_USB_NET_CDC_MBIM.

Fix by setting the altsetting back to default after the test, restoring the
previous behaviour for non MBIM devices.

This bug causes probing of Huawei E3276 devices to fail when the MBIM driver
is enabled, because these devices have a second alternate setting with no CDC
functional descriptors.

Reported-and-tested-by: Jonathan A. 
Cc: Greg Suarez 
Cc: Alexey Orishko 
Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

p54usb: corrected USB ID for T-Com Sinus 154 data II

2013-02-28T13:38:32+00:00

commit 008e33f733ca51acb2dd9d88ea878693b04d1d2a upstream.

Corrected USB ID for T-Com Sinus 154 data II. ISL3887-based. The
device was tested in managed mode with no security, WEP 128
bit and WPA-PSK (TKIP) with firmware 2.13.1.0.lm87.arm (md5sum:
7d676323ac60d6e1a3b6d61e8c528248). It works.

Signed-off-by: Tomasz Guszkowski 
Acked-By: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: usb: allocate URB control message setup_packet and data buffer separately

2013-02-28T13:38:30+00:00

commit bc6b89237acb3dee6af6e64e51a18255fef89cc2 upstream.

rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
	struct {
		u8 data[254];
		struct usb_ctrlrequest dr;
	};

Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.

Patch changes setup packet to be allocated separately.

[v2]:
 - Use WARN_ON_ONCE instead of WARN_ON

Signed-off-by: Jussi Kivilinna 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192cu: Add new USB ID

2013-02-28T13:38:30+00:00

commit 8708aac79e4572ba673d7a21e94ddca9f3abb7fc upstream.

A new model of the RTL8188CUS has appeared.

Reported-and-tested-by: Thomas Rosenkrantz 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman