linux/drivers/net, branch v2.6.34.1

iwlwifi: add missing rcu_read_lock

2010-07-05T18:22:53Z

commit 6db6340c42d027b6364d49fa99d69019aca24de4 upstream. Using ieee80211_find_sta() needs to be under RCU read lock, which iwlwifi currently misses, so fix it. Reported-by: Miles Lane Signed-off-by: Johannes Berg Acked-by: Reinette Chatre Tested-by: Miles Lane Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wl1251: fix a memory leak in probe

2010-07-05T18:22:53Z

commit aa679c36756003f1fabdb9fc6f00eb159559f7c3 upstream. wl1251_sdio_probe() error path is missing wl1251_free_hw, add it. Signed-off-by: Grazvydas Ignotas Acked-by: Kalle Valo Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: recalculate average tpt if not current

2010-07-05T18:22:51Z

commit 3d79b2a9eeaa066b35c49fbb17e3156a3c482c3e upstream. We currently have this check as a BUG_ON, which is being hit by people. Previously it was an error with a recalculation if not current, return that code. The BUG_ON was introduced by: commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749 Author: Guy Cohen Date: Tue Sep 9 10:54:54 2008 +0800 iwlwifi: Added support for 3 antennas ... the portion adding the BUG_ON is reverted since we are encountering the error and BUG_ON was created with assumption that error is not encountered. Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix internal scan race

2010-07-05T18:22:51Z

commit 073d5eab6fc85b6c278d507a5633b759a85dc878 upstream. It is possible for internal scan to race against itself if the device is not returning the scan results from first requests. What happens in this case is the cleanup done during the abort of the first internal scan also cleans up part of the new scan, causing it to access memory it shouldn't. Here are details: * First internal scan is triggered and scan command sent to device. * After seven seconds there is no scan results so the watchdog timer triggers a scan abort. * The scan abort succeeds and a SCAN_COMPLETE_NOTIFICATION is received for failed scan. * During processing of SCAN_COMPLETE_NOTIFICATION we clear STATUS_SCANNING and queue the "scan_completed" work. ** At this time, since the problem that caused the internal scan in first place is still present, a new internal scan is triggered. The behavior at this point is a bit different between 2.6.34 and 2.6.35 since 2.6.35 has a lot of this synchronized. The rest of the race description will thus be generalized. ** As part of preparing for the scan "is_internal_short_scan" is set to true. * At this point the completion work for fist scan is run. As part of this there is some locking missing around the "is_internal_short_scan" variable and it is set to "false". ** Now the second scan runs and it considers itself a real (not internal0 scan and thus causes problems with wrong memory being accessed. The fix is twofold. * Since "is_internal_short_scan" should be protected by mutex, fix this in scan completion work so that changes to it can be serialized. * Do not queue a new internal scan if one is in progress. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=15824 Signed-off-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

p54usb: Add device ID for Dell WLA3310 USB

2010-07-05T18:22:50Z

commit 0f666a08901f8b01f294ca0ad751019375240ae3 upstream. Add Dell WLA3310 USB wireless card, which has a Z-Com XG-705A chipset, to the USB Ids in p54usb. Signed-off-by: Jason Dravet Tested-by: Richard Gregory Tillmore Signed-off-by: Larry Finger Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath5k: retain promiscuous setting

2010-07-05T18:22:44Z

commit 6b5dcccb495b66b3b0b9581cdccfed038e5d68a2 upstream. Commit 56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up filter flags setting" introduced a regression in monitor mode such that the promisc filter flag would get lost. Although we set the promisc flag when it changed, we did not preserve it across subsequent calls to configure_filter. This patch restores the original functionality. Bisected-by: weedy2887@gmail.com Tested-by: weedy2887@gmail.com Tested-by: Rick Farina Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mlx4_core: Fix possible chunk sg list overflow in mlx4_alloc_icm()

2010-07-05T18:22:30Z

commit c0dc72bad9cf21071f5e4005de46f7c8b67a138a upstream. If the number of sg entries in the ICM chunk reaches MLX4_ICM_CHUNK_LEN, we must set chunk to NULL even for coherent mappings so that the next time through the loop will allocate another chunk. Otherwise we'll overflow the sg list the next time through the loop. This will lead to memory corruption if this case is hit. mthca does not have this bug. Signed-off-by: Sebastien Dugue Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

can: Fix SJA1000 command register writes on SMP systems

2010-07-05T18:22:15Z

commit 57c8a456640fa3ca777652f11f2db4179a3e66b6 upstream. The SJA1000 command register is concurrently written in the rx-path to free the receive buffer _and_ in the tx-path to start the transmission. The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states: "Between two commands at least one internal clock cycle is needed in order to proceed. The internal clock is half of the external oscillator frequency." On SMP systems the current implementation leads to a write stall in the tx-path, which can be solved by adding some general locking and some time to settle the write_reg() operation for the command register. Thanks to Klaus Hitschler for the original fix and detailed problem description. This patch applies on net-2.6 and (with some offsets) on net-next-2.6 . Signed-off-by: Oliver Hartkopp Acked-by: Wolfgang Grandegger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix hardware deinit

2010-07-05T18:22:14Z

commit 736b3a27b3c50c4a23717b802240435a69e8d0ff upstream. Without this you will get a panic if the device initialization fails. Also, free ath_hw instance properly. ath9k_hw_deinit() shouldn't do it. Signed-off-by: Sujith Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath5k: consistently use rx_bufsize for RX DMA

2010-07-05T18:22:10Z

commit b5eae9ff5ba6d76de19286dd6429acd7cde3f79d upstream. We should use the same buffer size we set up for DMA also in the hardware descriptor. Previously we used common->rx_bufsize for setting up the DMA mapping, but used skb_tailroom(skb) for the size we tell to the hardware in the descriptor itself. The problem is that skb_tailroom(skb) can give us a larger value than the size we set up for DMA before. This allows the hardware to write into memory locations not set up for DMA. In practice this should rarely happen because all packets should be smaller than the maximum 802.11 packet size. On the tested platform rx_bufsize is 2528, and we allocated an skb of 2559 bytes length (including padding for cache alignment) but sbk_tailroom() was 2592. Just consistently use rx_bufsize for all RX DMA memory sizes. Also use the return value of the descriptor setup function. Signed-off-by: Bruno Randolf Reviewed-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman