commit 9bf176a3e029ae7f2dc6feae185091525a988be2 Author: Greg Kroah-Hartman Date: Mon Mar 19 08:58:30 2012 -0700 Linux 3.0.25 commit 35f68010b4311eacf6340473b062418715d68a39 Author: Ville Syrjala Date: Thu Mar 15 18:11:05 2012 +0100 i2c-algo-bit: Fix spurious SCL timeouts under heavy load commit 8ee161ce5e0cfc689eb677f227a6248191165fac upstream. When the system is under heavy load, there can be a significant delay between the getscl() and time_after() calls inside sclhi(). That delay may cause the time_after() check to trigger after SCL has gone high, causing sclhi() to return -ETIMEDOUT. To fix the problem, double check that SCL is still low after the timeout has been reached, before deciding to return -ETIMEDOUT. Signed-off-by: Ville Syrjala Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 90b7d65c8cba8830ede8307a21a76c8757eefa3a Author: Guenter Roeck Date: Mon Mar 12 08:33:10 2012 -0700 hwmon: (w83627ehf) Fix memory leak in probe function commit 32260d94408c553dca4ce54104edf79941a27536 upstream. The driver probe function leaked memory if creating the cpu0_vid attribute file failed. Fix by converting the driver to use devm_kzalloc. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit baf9f08ae4a3e041e718b2e9843400faab15ccda Author: Guenter Roeck Date: Mon Mar 12 08:21:16 2012 -0700 hwmon: (w83627ehf) Fix writing into fan_stop_time for NCT6775F/NCT6776F commit 33fa9b620409edfc71aa6cf01a51f990fbe46ab8 upstream. NCT6775F and NCT6776F have their own set of registers for FAN_STOP_TIME. The correct registers were used to read FAN_STOP_TIME, but writes used the wrong registers. Fix it. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 0af6af909e28dc66e0ce8846fccf0e5a70c28415 Author: Jiri Slaby Date: Mon Mar 5 14:06:38 2012 +0100 compat: Re-add missing asm/compat.h include to fix compile breakage on s390 For 3.0 stable kernel the backport of 048cd4e51d24ebf7f3552226d03c769d6ad91658 "compat: fix compile breakage on s390" breaks compilation... Re-add a single #include in order to fix this. This patch is _not_ necessary for upstream, only for stable kernels which include the "build fix" mentioned above. One fix for arch/s390/kernel/setup.c was already sent and applied. But we need a similar patch for drivers/s390/char/fs3270.c. Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit d17a17faf0334f2c95e922fb21a612cfea5b99ce Author: David S. Miller Date: Tue Mar 13 18:19:51 2012 -0700 sparc32: Add -Av8 to assembler command line. commit e0adb9902fb338a9fe634c3c2a3e474075c733ba upstream. Newer version of binutils are more strict about specifying the correct options to enable certain classes of instructions. The sparc32 build is done for v7 in order to support sun4c systems which lack hardware integer multiply and divide instructions. So we have to pass -Av8 when building the assembler routines that use these instructions and get patched into the kernel when we find out that we have a v8 capable cpu. Reported-by: Paul Gortmaker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af73826949dc1ea1fd25990c0145a309fbe66b86 Author: Ben Hutchings Date: Sat Feb 25 00:03:10 2012 +0000 sfc: Fix assignment of ip_summed for pre-allocated skbs commit ff3bc1e7527504a93710535611b2f812f3bb89bf upstream. When pre-allocating skbs for received packets, we set ip_summed = CHECKSUM_UNNCESSARY. We used to change it back to CHECKSUM_NONE when the received packet had an incorrect checksum or unhandled protocol. Commit bc8acf2c8c3e43fcc192762a9f964b3e9a17748b ('drivers/net: avoid some skb->ip_summed initializations') mistakenly replaced the latter assignment with a DEBUG-only assertion that ip_summed == CHECKSUM_NONE. This assertion is always false, but it seems no-one has exercised this code path in a DEBUG build. Fix this by moving our assignment of CHECKSUM_UNNECESSARY into efx_rx_packet_gro(). Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 25705e3a3e9f91280b51124a28e74418aff00c7d Author: Alan Stern Date: Fri Mar 2 10:51:00 2012 +0100 Block: use a freezable workqueue for disk-event polling commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream. This patch (as1519) fixes a bug in the block layer's disk-events polling. The polling is done by a work routine queued on the system_nrt_wq workqueue. Since that workqueue isn't freezable, the polling continues even in the middle of a system sleep transition. Obviously, polling a suspended drive for media changes and such isn't a good thing to do; in the case of USB mass-storage devices it can lead to real problems requiring device resets and even re-enumeration. The patch fixes things by creating a new system-wide, non-reentrant, freezable workqueue and using it for disk-events polling. Signed-off-by: Alan Stern Acked-by: Tejun Heo Acked-by: Rafael J. Wysocki Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit aaa136d348dc723f45667aa8b39eb58c7e7c4383 Author: Stanislaw Gruszka Date: Fri Mar 2 10:43:28 2012 +0100 block: fix __blkdev_get and add_disk race condition commit 9f53d2fe815b4011ff930a7b6db98385d45faa68 upstream. The following situation might occur: __blkdev_get: add_disk: register_disk() get_gendisk() disk_block_events() disk->ev == NULL disk_add_events() __disk_unblock_events() disk->ev != NULL --ev->block Then we unblock events, when they are suppose to be blocked. This can trigger events related block/genhd.c warnings, but also can crash in sd_check_events() or other places. I'm able to reproduce crashes with the following scripts (with connected usb dongle as sdb disk). DEV=/dev/sdb ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValue function stop_me() { for i in `jobs -p` ; do kill $i 2> /dev/null ; done exit } trap stop_me SIGHUP SIGINT SIGTERM for ((i = 0; i < 10; i++)) ; do while true; do fdisk -l $DEV 2>&1 > /dev/null ; done & done while true ; do echo 1 > $ENABLE sleep 1 echo 0 > $ENABLE done I use the script to verify patch fixing oops in sd_revalidate_disk http://marc.info/?l=linux-scsi&m=132935572512352&w=2 Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in sd_revalidate_disk" or this one, script easily crash kernel within a few seconds. With both patches applied I do not observe crash. Unfortunately after some time (dozen of minutes), script will hung in: [ 1563.906432] [] schedule_timeout_uninterruptible+0x15/0x20 [ 1563.906437] [] msleep+0x15/0x20 [ 1563.906443] [] blk_drain_queue+0x32/0xd0 [ 1563.906447] [] blk_cleanup_queue+0xd0/0x170 [ 1563.906454] [] scsi_free_queue+0x3f/0x60 [ 1563.906459] [] __scsi_remove_device+0x6e/0xb0 [ 1563.906463] [] scsi_forget_host+0x4f/0x60 [ 1563.906468] [] scsi_remove_host+0x5a/0xf0 [ 1563.906482] [] quiesce_and_remove_host+0x5b/0xa0 [usb_storage] [ 1563.906490] [] usb_stor_disconnect+0x13/0x20 [usb_storage] Anyway I think this patch is some step forward. As drawback, I do not teardown on sysfs file create error, because I do not know how to nullify disk->ev (since it can be used). However add_disk error handling practically does not exist too, and things will work without this sysfs file, except events will not be exported to user space. Signed-off-by: Stanislaw Gruszka Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 30503b5edf8c1e3204280534d416f31fcb277aee Author: Dan Carpenter Date: Sat Mar 3 12:09:17 2012 +0100 block, sx8: fix pointer math issue getting fw version commit ea5f4db8ece896c2ab9eafa0924148a2596c52e4 upstream. "mem" is type u8. We need parenthesis here or it screws up the pointer math probably leading to an oops. Signed-off-by: Dan Carpenter Acked-by: Jeff Garzik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 57babcb863bb689d49db626b4b69ce3629001fc1 Author: Jun'ichi Nomura Date: Fri Mar 2 10:38:33 2012 +0100 block: Fix NULL pointer dereference in sd_revalidate_disk commit fe316bf2d5847bc5dd975668671a7b1067603bc7 upstream. Since 2.6.39 (1196f8b), when a driver returns -ENOMEDIUM for open(), __blkdev_get() calls rescan_partitions() to remove in-kernel partition structures and raise KOBJ_CHANGE uevent. However it ends up calling driver's revalidate_disk without open and could cause oops. In the case of SCSI: process A process B ---------------------------------------------- sys_open __blkdev_get sd_open returns -ENOMEDIUM scsi_remove_device rescan_partitions sd_revalidate_disk Oopses are reported here: http://marc.info/?l=linux-scsi&m=132388619710052 This patch separates the partition invalidation from rescan_partitions() and use it for -ENOMEDIUM case. Reported-by: Huajun Li Signed-off-by: Jun'ichi Nomura Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9225c509838dfef1d004552f8d909434812fc966 Author: Axel Lin Date: Thu Mar 8 10:02:17 2012 +0800 regulator: Fix setting selector in tps6524x set_voltage function commit f03570cf1709397ebe656608266b44ec772960c2 upstream. Don't assign the voltage to selector. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 508e8376b63e20e9191d3b80a3b32a31d0566aee Author: Heiko Carstens Date: Mon Mar 5 14:06:38 2012 +0100 compat: Re-add missing asm/compat.h include to fix compile breakage on s390 For kernels <= 3.0 the backport of 048cd4e51d24ebf7f3552226d03c769d6ad91658 "compat: fix compile breakage on s390" will break compilation... Re-add a single #include in order to fix this. This patch is _not_ necessary for upstream, only for stable kernels which include the "build fix" mentioned above. Reported-by: Jiri Slaby Signed-off-by: Heiko Carstens commit aaff6e3506d676b22946677798f16e3bb6e40028 Author: Joerg Neikes Date: Thu Mar 8 22:44:03 2012 +0000 usb: asix: Patch for Sitecom LN-031 commit 4e50391968849860dff1aacde358b4eb14aa5127 upstream. This patch adds support for the Sitecom LN-031 USB adapter with a AX88178 chip. Added USB id to find correct driver for AX88178 1000 Ethernet adapter. Signed-off-by: Joerg Neikes Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f27ce05c2be6cb27a3cee72c4ec4794556d6ef9d Author: Eric Dumazet Date: Wed Feb 15 20:43:11 2012 +0000 atl1c: dont use highprio tx queue [ Upstream commit 11aad99af6ef629ff3b05d1c9f0936589b204316 ] This driver attempts to use two TX rings but lacks proper support : 1) IRQ handler only takes care of TX completion on first TX ring 2) the stop/start logic uses the legacy functions (for non multiqueue drivers) This means all packets witk skb mark set to 1 are sent through high queue but are never cleaned and queue eventualy fills and block the device, triggering the infamous "NETDEV WATCHDOG" message. Lets use a single TX ring to fix the problem, this driver is not a real multiqueue one yet. Minimal fix for stable kernels. Reported-by: Thomas Meyer Tested-by: Thomas Meyer Signed-off-by: Eric Dumazet Cc: Jay Cliburn Cc: Chris Snook Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 94962718da9d6df11a3a30511016707e4e9451dc Author: Li Wei Date: Mon Mar 5 14:45:17 2012 +0000 IPv6: Fix not join all-router mcast group when forwarding set. [ Upstream commit d6ddef9e641d1229d4ec841dc75ae703171c3e92 ] When forwarding was set and a new net device is register, we need add this device to the all-router mcast group. Signed-off-by: Li Wei Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 619b6e476fdf85f17d80df72f647f2fb85535339 Author: Neal Cardwell Date: Mon Mar 5 19:35:04 2012 +0000 tcp: fix tcp_shift_skb_data() to not shift SACKed data below snd_una [ Upstream commit 4648dc97af9d496218a05353b0e442b3dfa6aaab ] This commit fixes tcp_shift_skb_data() so that it does not shift SACKed data below snd_una. This fixes an issue whose symptoms exactly match reports showing tp->sacked_out going negative since 3.3.0-rc4 (see "WARNING: at net/ipv4/tcp_input.c:3418" thread on netdev). Since 2008 (832d11c5cd076abc0aa1eaf7be96c81d1a59ce41) tcp_shift_skb_data() had been shifting SACKed ranges that were below snd_una. It checked that the *end* of the skb it was about to shift from was above snd_una, but did not check that the end of the actual shifted range was above snd_una; this commit adds that check. Shifting SACKed ranges below snd_una is problematic because for such ranges tcp_sacktag_one() short-circuits: it does not declare anything as SACKed and does not increase sacked_out. Before the fixes in commits cc9a672ee522d4805495b98680f4a3db5d0a0af9 and daef52bab1fd26e24e8e9578f8fb33ba1d0cb412, shifting SACKed ranges below snd_una happened to work because tcp_shifted_skb() was always (incorrectly) passing in to tcp_sacktag_one() an skb whose end_seq tcp_shift_skb_data() had already guaranteed was beyond snd_una. Hence tcp_sacktag_one() never short-circuited and always increased tp->sacked_out in this case. After those two fixes, my testing has verified that shifting SACKed ranges below snd_una could cause tp->sacked_out to go negative with the following sequence of events: (1) tcp_shift_skb_data() sees an skb whose end_seq is beyond snd_una, then shifts a prefix of that skb that is below snd_una (2) tcp_shifted_skb() increments the packet count of the already-SACKed prev sk_buff (3) tcp_sacktag_one() sees the end of the new SACKed range is below snd_una, so it short-circuits and doesn't increase tp->sacked_out (5) tcp_clean_rtx_queue() sees the SACKed skb has been ACKed, decrements tp->sacked_out by this "inflated" pcount that was missing a matching increase in tp->sacked_out, and hence tp->sacked_out underflows to a u32 like 0xFFFFFFFF, which casted to s32 is negative. (6) this leads to the warnings seen in the recent "WARNING: at net/ipv4/tcp_input.c:3418" thread on the netdev list; e.g.: tcp_input.c:3418 WARN_ON((int)tp->sacked_out < 0); More generally, I think this bug can be tickled in some cases where two or more ACKs from the receiver are lost and then a DSACK arrives that is immediately above an existing SACKed skb in the write queue. This fix changes tcp_shift_skb_data() to abort this sequence at step (1) in the scenario above by noticing that the bytes are below snd_una and not shifting them. Signed-off-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b77a726051a42d382ec1d20c49b3a60bf7dd54d8 Author: Ulrich Weber Date: Mon Mar 5 04:52:44 2012 +0000 bridge: check return value of ipv6_dev_get_saddr() [ Upstream commit d1d81d4c3dd886d5fa25a2c4fa1e39cb89613712 ] otherwise source IPv6 address of ICMPV6_MGM_QUERY packet might be random junk if IPv6 is disabled on interface or link-local address is not yet ready (DAD). Signed-off-by: Ulrich Weber Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6046dc7d1b061d0f8e820757716de7df5079aa35 Author: Neal Cardwell Date: Fri Mar 2 21:36:51 2012 +0000 tcp: don't fragment SACKed skbs in tcp_mark_head_lost() [ Upstream commit c0638c247f559e1a16ee79e54df14bca2cb679ea ] In tcp_mark_head_lost() we should not attempt to fragment a SACKed skb to mark the first portion as lost. This is for two primary reasons: (1) tcp_shifted_skb() coalesces adjacent regions of SACKed skbs. When doing this, it preserves the sum of their packet counts in order to reflect the real-world dynamics on the wire. But given that skbs can have remainders that do not align to MSS boundaries, this packet count preservation means that for SACKed skbs there is not necessarily a direct linear relationship between tcp_skb_pcount(skb) and skb->len. Thus tcp_mark_head_lost()'s previous attempts to fragment off and mark as lost a prefix of length (packets - oldcnt)*mss from SACKed skbs were leading to occasional failures of the WARN_ON(len > skb->len) in tcp_fragment() (which used to be a BUG_ON(); see the recent "crash in tcp_fragment" thread on netdev). (2) there is no real point in fragmenting off part of a SACKed skb and calling tcp_skb_mark_lost() on it, since tcp_skb_mark_lost() is a NOP for SACKed skbs. Signed-off-by: Neal Cardwell Acked-by: Ilpo Järvinen Acked-by: Yuchung Cheng Acked-by: Nandita Dukkipati Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c27d38f6437b01f53915dc1772bfae75fe5430c2 Author: Shreyas Bhatewara Date: Tue Feb 28 22:17:38 2012 +0000 vmxnet3: Fix transport header size [ Upstream commit efead8710aad9e384730ecf25eae0287878840d7 ] Fix transport header size Fix the transpoert header size for UDP packets. Signed-off-by: Shreyas N Bhatewara Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 85526d578a0c7b6723c1a429b39870ce3bfec11c Author: Neal Cardwell Date: Sun Feb 26 10:06:19 2012 +0000 tcp: fix false reordering signal in tcp_shifted_skb [ Upstream commit 4c90d3b30334833450ccbb02f452d4972a3c3c3f ] When tcp_shifted_skb() shifts bytes from the skb that is currently pointed to by 'highest_sack' then the increment of TCP_SKB_CB(skb)->seq implicitly advances tcp_highest_sack_seq(). This implicit advancement, combined with the recent fix to pass the correct SACKed range into tcp_sacktag_one(), caused tcp_sacktag_one() to think that the newly SACKed range was before the tcp_highest_sack_seq(), leading to a call to tcp_update_reordering() with a degree of reordering matching the size of the newly SACKed range (typically just 1 packet, which is a NOP, but potentially larger). This commit fixes this by simply calling tcp_sacktag_one() before the TCP_SKB_CB(skb)->seq advancement that can advance our notion of the highest SACKed sequence. Correspondingly, we can simplify the code a little now that tcp_shifted_skb() should update the lost_cnt_hint in all cases where skb == tp->lost_skb_hint. Signed-off-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2991ddd266470f77442bfb023b2737b6920f8715 Author: Ben McKeegan Date: Fri Feb 24 06:33:56 2012 +0000 ppp: fix 'ppp_mp_reconstruct bad seq' errors [ Upstream commit 8a49ad6e89feb5015e77ce6efeb2678947117e20 ] This patch fixes a (mostly cosmetic) bug introduced by the patch 'ppp: Use SKB queue abstraction interfaces in fragment processing' found here: http://www.spinics.net/lists/netdev/msg153312.html The above patch rewrote and moved the code responsible for cleaning up discarded fragments but the new code does not catch every case where this is necessary. This results in some discarded fragments remaining in the queue, and triggering a 'bad seq' error on the subsequent call to ppp_mp_reconstruct. Fragments are discarded whenever other fragments of the same frame have been lost. This can generate a lot of unwanted and misleading log messages. This patch also adds additional detail to the debug logging to make it clearer which fragments were lost and which other fragments were discarded as a result of losses. (Run pppd with 'kdebug 1' option to enable debug logging.) Signed-off-by: Ben McKeegan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e38b849e2fc481c5a6924f6872468104969e5d3c Author: Eric Dumazet Date: Thu Feb 23 10:55:02 2012 +0000 ipsec: be careful of non existing mac headers [ Upstream commit 03606895cd98c0a628b17324fd7b5ff15db7e3cd ] Niccolo Belli reported ipsec crashes in case we handle a frame without mac header (atm in his case) Before copying mac header, better make sure it is present. Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809 Reported-by: Niccolò Belli Tested-by: Niccolò Belli Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 035e3f6e8d1353abcbefd5b87710f8ae8bf1b4f6 Author: Michel Machado Date: Tue Feb 21 11:04:13 2012 +0000 neighbour: Fixed race condition at tbl->nht [ Upstream commit 84338a6c9dbb6ff3de4749864020f8f25d86fc81 ] When the fixed race condition happens: 1. While function neigh_periodic_work scans the neighbor hash table pointed by field tbl->nht, it unlocks and locks tbl->lock between buckets in order to call cond_resched. 2. Assume that function neigh_periodic_work calls cond_resched, that is, the lock tbl->lock is available, and function neigh_hash_grow runs. 3. Once function neigh_hash_grow finishes, and RCU calls neigh_hash_free_rcu, the original struct neigh_hash_table that function neigh_periodic_work was using doesn't exist anymore. 4. Once back at neigh_periodic_work, whenever the old struct neigh_hash_table is accessed, things can go badly. Signed-off-by: Michel Machado CC: "David S. Miller" CC: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7affb2673c36d8fb93ac39e889b674c95eb3c8f8 Author: Ike Panhc Date: Fri Feb 3 16:46:39 2012 +0800 acer-wmi: No wifi rfkill on Lenovo machines commit 461e74377cfcfc2c0d6bbdfa8fc5fbc21b052c2a upstream. We have several reports which says acer-wmi is loaded on ideapads and register rfkill for wifi which can not be unblocked. Since ideapad-laptop also register rfkill for wifi and it works reliably, it will be fine acer-wmi is not going to register rfkill for wifi once VPC2004 is found. Also put IBM0068/LEN0068 in the list. Though thinkpad_acpi has no wifi rfkill capability, there are reports which says acer-wmi also block wireless on Thinkpad E520/E420. Signed-off-by: Ike Panhc Signed-off-by: Matthew Garrett Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman commit 2b033b873b428b01d8508ba9f0c56b9246ab31b4 Author: Lee, Chun-Yi Date: Thu Aug 18 18:47:33 2011 +0800 acer-wmi: check wireless capability flag before register rfkill commit 1709adab0773616da7a8190f2762e599afb0a295 upstream. There will be better to check the wireless capability flag (ACER_CAP_WIRELESS) before register wireless rfkill because maybe the machine doesn't have wifi module or the module removed by user. Tested on Acer Travelmate 8572 Tested on Acer Aspire 4739Z Tested-by: AceLan Kao Cc: Carlos Corbacho Cc: Matthew Garrett Cc: Dmitry Torokhov Cc: Corentin Chary Cc: Thomas Renninger Signed-off-by: Lee, Chun-Yi Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit bbc1505482e5bb16fa956e23f22dae6cd25172e6 Author: Seth Forshee Date: Thu Oct 6 15:01:55 2011 -0500 acer-wmi: Add wireless quirk for Lenovo 3000 N200 commit be3128b107e36271f7973ef213ccde603a494fe8 upstream. This quirk fixes the wlan rfkill status on this machine. Without it, wlan is permanently soft blocked whenever acer-wmi is loaded. BugLink: https://bugs.launchpad.net/bugs/857297 Signed-off-by: Seth Forshee Reviewed-by: Lee, Chun-Yi Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit ac7c1239fae01813ea4517f2b11aec7b4020f3a1 Author: Lee, Chun-Yi Date: Sat Jul 30 17:00:45 2011 +0800 acer-wmi: support Lenovo ideapad S205 wifi switch commit 15b956a0b5651bbb1217ec374fdd67291dabb2af upstream. The AMW0 function in acer-wmi works on Lenovo ideapad S205 for control the wifi hardware state. We also found there have a 0x78 EC register exposes the state of wifi hardware switch on the machine. So, add this patch to support Lenovo ideapad S205 wifi hardware switch in acer-wmi driver. Reference: bko#37892 https://bugzilla.kernel.org/show_bug.cgi?id=37892 Cc: Carlos Corbacho Cc: Matthew Garrett Cc: Dmitry Torokhov Cc: Corentin Chary Cc: Thomas Renninger Tested-by: Florian Heyer Signed-off-by: Lee, Chun-Yi Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 8b5cfa43c4e9e9042c77a4683d1b747329dbb2cf Author: Miklos Szeredi Date: Tue Mar 6 13:56:33 2012 +0100 vfs: fix double put after complete_walk() commit 097b180ca09b581ef0dc24fbcfc1b227de3875df upstream. complete_walk() already puts nd->path, no need to do it again at cleanup time. This would result in Oopses if triggered, apparently the codepath is not too well exercised. Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 9a2317b6ce52b4983699cbdd4634d3590f7cacaa Author: Miklos Szeredi Date: Tue Mar 6 13:56:34 2012 +0100 vfs: fix return value from do_last() commit 7f6c7e62fcc123e6bd9206da99a2163fe3facc31 upstream. complete_walk() returns either ECHILD or ESTALE. do_last() turns this into ECHILD unconditionally. If not in RCU mode, this error will reach userspace which is complete nonsense. Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 60d3a450571b3d92f5f9f78f2898a7f425031b51 Author: Stanislaw Gruszka Date: Fri Mar 9 12:39:54 2012 +0100 rt2x00: fix random stalls commit 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 upstream. Is possible that we stop queue and then do not wake up it again, especially when packets are transmitted fast. That can be easily reproduced with modified tx queue entry_num to some small value e.g. 16. If mac80211 already hold local->queue_stop_reason_lock, then we can wait on that lock in both rt2x00queue_pause_queue() and rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock is possible that __ieee80211_wake_queue() will be performed before __ieee80211_stop_queue(), hence we stop queue and newer wake up it again. Another race condition is possible when between rt2x00queue_threshold() check and rt2x00queue_pause_queue() we will process all pending tx buffers on different cpu. This might happen if for example interrupt will be triggered on cpu performing rt2x00mac_tx(). To prevent race conditions serialize pause/unpause by queue->tx_lock. Signed-off-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit aca7c0631efe6b28623bab2c9a02931aa25d4640 Author: Alan Stern Date: Tue Dec 6 23:24:52 2011 +0100 PM / Driver core: leave runtime PM enabled during system shutdown commit fe6b91f47080eb17d21cbf2a39311877d57f6938 upstream. Disabling all runtime PM during system shutdown turns out not to be a good idea, because some devices may need to be woken up from a low-power state at that time. The whole point of disabling runtime PM for system shutdown was to prevent untimely runtime-suspend method calls. This patch (as1504) accomplishes the same result by incrementing the usage count for each device and waiting for ongoing runtime-PM callbacks to finish. This is what we already do during system suspend and hibernation, which makes sense since the shutdown method is pretty much a legacy analog of the pm->poweroff method. This fixes a recent regression on some OMAP systems introduced by commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 (PM / driver core: disable device's runtime PM during shutdown). Reported-and-tested-by: NeilBrown Signed-off-by: Alan Stern Acked-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki Cc: Kostyantyn Shlyakhovoy Signed-off-by: Greg Kroah-Hartman commit 9bfaf9d147e8df52e3e9499b87ae007afda64c25 Author: Stefan Richter Date: Sun Aug 7 15:20:18 2011 +0200 firewire: core: handle ack_busy when fetching the Config ROM commit aaff12039ffd812d0c8bbff50b87b6f1f09bec3e upstream. Some older Panasonic made camcorders (Panasonic AG-EZ30 and NV-DX110, Grundig Scenos DLC 2000) reject requests with ack_busy_X if a request is sent immediately after they sent a response to a prior transaction. This causes firewire-core to fail probing of the camcorder with "giving up on config rom for node id ...". Consequently, programs like kino or dvgrab are unaware of the presence of a camcorder. Such transaction failures happen also with the ieee1394 driver stack (of the 2.4...2.6 kernel series until 2.6.36 inclusive) but with a lower likelihood, such that kino or dvgrab are generally able to use these camcorders via the older driver stack. The cause for firewire-ohci's or firewire-core's worse behavior is not yet known. Gap count optimization in firewire-core is not the cause. Perhaps the slightly higher latency of transaction completion in the older stack plays a role. (ieee1394: AR-resp DMA context tasklet -> packet completion ktread -> user process; firewire-core: tasklet -> user process.) This change introduces retries and delays after ack_busy_X into firewire-core's Config ROM reader, such that at least firewire-core's probing and /dev/fw* creation are successful. This still leaves the problem that userland processes are facing transaction failures. gscanbus's built-in retry routines deal with them successfully, but neither kino's nor dvgrab's do ever succeed. But at least DV capture with "dvgrab -noavc -card 0" works now. Live video preview in kino works too, but not actual capture. One way to prevent Configuration ROM reading failures in application programs is to modify libraw1394 to synthesize read responses by means of firewire-core's Configuration ROM cache. This would only leave CMP and FCP transaction failures as a potential problem source for applications. Reported-and-tested-by: Thomas Seilund Reported-and-tested-by: René Fritz Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 4995a6913d6ada9672179736affd5606f2281edb Author: Stefan Richter Date: Thu Aug 11 00:06:04 2011 +0200 firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases commit 9c1176b6a28850703ea6e3a0f0c703f6d6c61cd3 upstream. Clemens points out that we need to use compat_ptr() in order to safely cast from u64 to addresses of a 32-bit usermode client. Before, our conversion went wrong - in practice if the client cast from pointer to integer such that sign-extension happened, (libraw1394 and libdc1394 at least were not doing that, IOW were not affected) or - in theory on s390 (which doesn't have FireWire though) and on the tile architecture, regardless of what the client does. The bug would usually be observed as the initial get_info ioctl failing with "Bad address" (EFAULT). Reported-by: Carl Karsten Reported-by: Clemens Ladisch Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 9217bfbbade56ef9dfee88773c2105e619028fa1 Author: Matthew Garrett Date: Tue Mar 6 13:41:49 2012 -0500 PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled commit 4949be16822e92a18ea0cc1616319926628092ee upstream. Right now we won't touch ASPM state if ASPM is disabled, except in the case where we find a device that appears to be too old to reliably support ASPM. Right now we'll clear it in that case, which is almost certainly the wrong thing to do. The easiest way around this is just to disable the blacklisting when ASPM is disabled. Signed-off-by: Matthew Garrett Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 5bcb3f882ab97f3ebb4c4abd435704ad24c565cb Author: Thomas Gleixner Date: Fri Mar 9 20:55:10 2012 +0100 x86: Derandom delay_tsc for 64 bit commit a7f4255f906f60f72e00aad2fb000939449ff32e upstream. Commit f0fbf0abc093 ("x86: integrate delay functions") converted delay_tsc() into a random delay generator for 64 bit. The reason is that it merged the mostly identical versions of delay_32.c and delay_64.c. Though the subtle difference of the result was: static void delay_tsc(unsigned long loops) { - unsigned bclock, now; + unsigned long bclock, now; Now the function uses rdtscl() which returns the lower 32bit of the TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64 bit this fails when the lower 32bit are close to wrap around when bclock is read, because the following check if ((now - bclock) >= loops) break; evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0 because the unsigned long (now - bclock) of these values results in 0xffffffff00000001 which is definitely larger than the loops value. That explains Tvortkos observation: "Because I am seeing udelay(500) (_occasionally_) being short, and that by delaying for some duration between 0us (yep) and 491us." Make those variables explicitely u32 again, so this works for both 32 and 64 bit. Reported-by: Tvrtko Ursulin Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e808b6adb5d0cfef4ab82a210bc680003b200e77 Author: Al Viro Date: Thu Mar 8 17:51:19 2012 +0000 aio: fix the "too late munmap()" race commit c7b285550544c22bc005ec20978472c9ac7138c6 upstream. Current code has put_ioctx() called asynchronously from aio_fput_routine(); that's done *after* we have killed the request that used to pin ioctx, so there's nothing to stop io_destroy() waiting in wait_for_all_aios() from progressing. As the result, we can end up with async call of put_ioctx() being the last one and possibly happening during exit_mmap() or elf_core_dump(), neither of which expects stray munmap() being done to them... We do need to prevent _freeing_ ioctx until aio_fput_routine() is done with that, but that's all we care about - neither io_destroy() nor exit_aio() will progress past wait_for_all_aios() until aio_fput_routine() does really_put_req(), so the ioctx teardown won't be done until then and we don't care about the contents of ioctx past that point. Since actual freeing of these suckers is RCU-delayed, we don't need to bump ioctx refcount when request goes into list for async removal. All we need is rcu_read_lock held just over the ->ctx_lock-protected area in aio_fput_routine(). Signed-off-by: Al Viro Reviewed-by: Jeff Moyer Acked-by: Benjamin LaHaise Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8ef749e355dfb8932d4ae6d4aa8eacf3b0ab4444 Author: Al Viro Date: Wed Mar 7 05:16:35 2012 +0000 aio: fix io_setup/io_destroy race commit 86b62a2cb4fc09037bbce2959d2992962396fd7f upstream. Have ioctx_alloc() return an extra reference, so that caller would drop it on success and not bother with re-grabbing it on failure exit. The current code is obviously broken - io_destroy() from another thread that managed to guess the address io_setup() would've returned would free ioctx right under us; gets especially interesting if aio_context_t * we pass to io_setup() points to PROT_READ mapping, so put_user() fails and we end up doing io_destroy() on kioctx another thread has just got freed... Signed-off-by: Al Viro Acked-by: Benjamin LaHaise Reviewed-by: Jeff Moyer Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d9de88703f09127c0902a6c24178adf4d1a29aa Author: Denis 'GNUtoo' Carikli Date: Sun Feb 26 19:21:54 2012 +0100 ASoC: neo1973: fix neo1973 wm8753 initialization commit b2ccf065f7b23147ed135a41b01d05a332ca6b7e upstream. The neo1973 driver had wrong codec name which prevented the "sound card" from appearing. Signed-off-by: Denis 'GNUtoo' Carikli Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman