commit a1092bf3809c7ec7b730d0cca3bdba964a813147 Author: Greg Kroah-Hartman Date: Fri Dec 18 14:27:07 2009 -0800 Linux 2.6.32.2 commit 80c0299b8cfdf7aa31b88118b75de6b7bb1aba63 Author: Luck, Tony Date: Mon Dec 14 20:00:36 2009 +0000 implement early_io{re,un}map for ia64 commit cd7bcf32d42b15891620b3f1387a00178b54291a upstream. Needed for commit 2c992208 ("intel-iommu: Detect DMAR in hyperspace at probe time.) to build on IA64. Signed-off-by: Tony Luck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 517361c51d4a762531e669ebb2c081a1e678455a Author: Paul Mackerras Date: Tue Dec 15 19:40:32 2009 +1100 perf_event: Fix incorrect range check on cpu number commit 0f624e7e5625f4c30c836b7a5decfe2553582391 upstream. It is quite legitimate for CPUs to be numbered sparsely, meaning that it possible for an online CPU to have a number which is greater than the total count of possible CPUs. Currently find_get_context() has a sanity check on the cpu number where it checks it against num_possible_cpus(). This test can fail for a legitimate cpu number if the cpu_possible_mask is sparsely populated. This fixes the problem by checking the CPU number against nr_cpumask_bits instead, since that is the appropriate check to ensure that the cpu number is same to pass to cpu_isset() subsequently. Reported-by: Michael Neuling Signed-off-by: Paul Mackerras Tested-by: Michael Neuling Acked-by: Peter Zijlstra LKML-Reference: <20091215084032.GA18661@brick.ozlabs.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 60a48f8c19f1de13a99ad6d1972bbde8d193f3bd Author: Jan Engelhardt Date: Mon Dec 14 14:52:10 2009 +0100 netfilter: xtables: document minimal required version commit 7a92263705435d046d37a0990d0edfcb517f7ad3 upstream. For both .33 and .32-stable. Signed-off-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit acb724d43ade7509f3dcec679243f88e2902c237 Author: Chris Wright Date: Wed Dec 2 12:06:34 2009 -0800 intel-iommu: ignore page table validation in pass through mode commit 1672af1164d3d50ba8908014fd34cc0b58afdc1e upstream. We are seeing a bug when booting w/ iommu=pt with current upstream (bisect blames 19943b0e30b05d42e494ae6fef78156ebc8c637e "intel-iommu: Unify hardware and software passthrough support). The issue is specific to this loop during identity map initialization of each device: domain_context_mapping_one(si_domain, ..., CONTEXT_TT_PASS_THROUGH) ... /* Skip top levels of page tables for * iommu which has less agaw than default. */ for (agaw = domain->agaw; agaw != iommu->agaw; agaw--) { pgd = phys_to_virt(dma_pte_addr(pgd)); if (!dma_pte_present(pgd)) { <------ failing here spin_unlock_irqrestore(&iommu->lock, flags); return -ENOMEM; } This box has 2 iommu's in it. The catchall iommu has MGAW == 48, and SAGAW == 4. The other iommu has MGAW == 39, SAGAW == 2. The device that's failing the above pgd test is the only device connected to the non-catchall iommu, which has a smaller address width than the domain default. This test is not necessary since the context is in PT mode and the ASR is ignored. Thanks to Don Dutile for discovering and debugging this one. Signed-off-by: Chris Wright Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 020d1eecf345422d34bec8fb4a45299dcc0dcc3f Author: David Woodhouse Date: Wed Dec 2 10:18:30 2009 +0000 intel-iommu: Fix oops with intel_iommu=igfx_off commit 44cd613c0e4cd93079ea2a93aa06649d8ca0830a upstream. The hotplug notifier will call find_domain() to see if the device in question has been assigned an IOMMU domain. However, this should never be called for devices with a "dummy" domain, such as graphics devices when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even initialised. If you do that, it'll oops as it dereferences the (-1) pointer. The notifier function should check iommu_no_mapping() for the device before doing anything else. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 39035f9c09699eea2dd154d170919dcd41c6885d Author: David Woodhouse Date: Wed Dec 2 09:21:55 2009 +0000 intel-iommu: Check for an RMRR which ends before it starts. commit 5595b528b49a702c0428c0762bab60999648254c upstream. Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping in the IOMMU for a given device) which has an end address lower than its start address. Detect that and warn, rather than triggering the BUG() in dma_pte_clear_range(). Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit b02375be25be8895f1fdb63a0962fd465d88f998 Author: David Woodhouse Date: Wed Dec 2 09:20:27 2009 +0000 intel-iommu: Apply BIOS sanity checks for interrupt remapping too. commit 6ecbf01c7ce4c0f4c3bdfa0e64ac6258328fda6c upstream. The BIOS errors where an IOMMU is reported either at zero or a bogus address are causing problems even when the IOMMU is disabled -- because interrupt remapping uses the same hardware. Ensure that the checks get applied for the interrupt remapping initialisation too. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 518cdfa0f604c285cdb71e1f2e2e14773f80bb01 Author: Chris Wright Date: Wed Dec 2 09:17:13 2009 +0000 intel-iommu: Detect DMAR in hyperspace at probe time. commit 2c99220810c1c79322034628b993573b088ff2da upstream. Many BIOSes will lie to us about the existence of an IOMMU, and claim that there is one at an address which actually returns all 0xFF. We need to detect this early, so that we know we don't have a viable IOMMU and can set up swiotlb before it's too late. Signed-off-by: Chris Wright Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 3a03456dc34ff703e5b7c718b78713577f832116 Author: David Woodhouse Date: Wed Dec 16 03:27:20 2009 +0000 jffs2: Fix long-standing bug with symlink garbage collection. commit 2e16cfca6e17ae37ae21feca080a6f2eca9087dc upstream. Ever since jffs2_garbage_collect_metadata() was first half-written in February 2001, it's been broken on architectures where 'char' is signed. When garbage collecting a symlink with target length above 127, the payload length would end up negative, causing interesting and bad things to happen. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 75bc75ed15405655d795a163856158aa2ff9bdbc Author: Simon Horman Date: Tue Dec 15 17:01:25 2009 +0100 ipvs: zero usvc and udest commit 258c889362aa95d0ab534b38ce8c15d3009705b1 upstream. Make sure that any otherwise uninitialised fields of usvc are zero. This has been obvserved to cause a problem whereby the port of fwmark services may end up as a non-zero value which causes scheduling of a destination server to fail for persisitent services. As observed by Deon van der Merwe . This fix suggested by Julian Anastasov . For good measure also zero udest. Cc: Deon van der Merwe Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit 1c723eb018de64d2159e9ce66ec6df0d1798e1e3 Author: Hugh Dickins Date: Mon Dec 14 17:59:04 2009 -0800 mm: sigbus instead of abusing oom commit d99be1a8ecf377c2c9b3372d36411ad6547bbd4c upstream. When do_nonlinear_fault() realizes that the page table must have been corrupted for it to have been called, it does print_bad_pte() and returns ... VM_FAULT_OOM, which is hard to understand. It made some sense when I did it for 2.6.15, when do_page_fault() just killed the current process; but nowadays it lets the OOM killer decide who to kill - so page table corruption in one process would be liable to kill another. Change it to return VM_FAULT_SIGBUS instead: that doesn't guarantee that the process will be killed, but is good enough for such a rare abnormality, accompanied as it is by the "BUG: Bad page map" message. And recent HWPOISON work has copied that code into do_swap_page(), when it finds an impossible swap entry: fix that to VM_FAULT_SIGBUS too. Signed-off-by: Hugh Dickins Cc: Izik Eidus Cc: Andrea Arcangeli Cc: Nick Piggin Reviewed-by: KOSAKI Motohiro Cc: Rik van Riel Cc: Lee Schermerhorn Cc: Andi Kleen Reviewed-by: KAMEZAWA Hiroyuki Reviewed-by: Wu Fengguang Reviewed-by: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ac34851f4dac996125b1cf7c5acdb14310b0f525 Author: Zhenyu Wang Date: Wed Nov 25 13:09:38 2009 +0800 drm/i915: Fix LVDS stability issue on Ironlake commit 1b3c7a47f993bf9ab6c4c7cc3bbf5588052b58f4 upstream. In disable sequence, all output ports on PCH have to be disabled before PCH transcoder, but LVDS port was left always enabled. This one fixes that by disable LVDS port properly during pipe disable process, and resolved stability issue seen on Ironlake. Also move panel fitting disable time just after pipe disable to align with the spec. Signed-off-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit fb79085d52de31fa0e2fe6cb9d1aab332caec16a Author: Zhenyu Wang Date: Fri Nov 27 11:44:36 2009 +0800 drm/i915: PineView only has LVDS and CRT ports commit 103a196f4224dc6872081305cf7f82ebf67aa7bd upstream. PineView only has 2 ports for LVDS and CRT. Don't enable other ports for it. Cc: Shaohua Li Signed-off-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 452a68706c276224ce1c91fff9ca88158d53c426 Author: Chris Wilson Date: Fri Nov 27 13:06:56 2009 +0000 drm/i915: Avoid NULL dereference with component_only tv_modes commit d271817baecbccb47da0d9f28c285a0dae8a06b7 upstream. In commit d2d9f2324, the guard for a valid video mode was removed. This caused the regression: kernel crash during kms graphic boot on Intel GM4500 platform https://bugzilla.redhat.com/show_bug.cgi?id=540218 This patches changes the logic slightly not to rely on a coupled variable, but to just check whether the video_modes is valid before dereferencing. Signed-off-by: Chris Wilson Cc: David Woodhouse Cc: Zhenyu Wang [ickle: Actually reference the correct bug report] Acked-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 21fc7b8d8c49b0f6ce7a45ae44361d31e93e629a Author: Yong Wang Date: Wed Dec 16 12:58:46 2009 +0800 x86: Under BIOS control, restore AP's APIC_LVTTHMR to the BSP value Upstream commit a2202aa29289db64ca7988b12343158b67b27f10. On platforms where bios handles the thermal monitor interrupt, APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS can't touch it. Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all the LVT entries except the mask bit. Essentially this results in all LVT entries including the thermal monitoring interrupt set to masked (clearing the bios programmed value for APIC_LVTTHMR). And this leads to kernel take over the thermal monitoring interrupt on AP's but not on BSP (leaving the bios programmed value only on BSP). As a result of this, we have seen system hangs when the thermal monitoring interrupt is generated. Fix this by reading the initial value of thermal LVT entry on BSP and if bios has taken over the control, then program the same value on all AP's and leave the thermal monitoring interrupt control on all the logical cpu's to the bios. Signed-off-by: Yong Wang Reviewed-by: Suresh Siddha Cc: Borislav Petkov Cc: Arjan van de Ven LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2e20f8fadd921fa3d664bb120f99b380a1b05cbd Author: Florian Fainelli Date: Tue Dec 15 06:45:06 2009 +0000 bcm63xx_enet: fix compilation failure after get_stats_count removal commit a3f92eea04101d9a8e14d50f8048cc5b7bca07a8 upstream. This patch converts bcm63xx_enet to uset get_sset_count like the other drivers do. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 21bcbffae11d48b81ca7b4fd0c873e4d8607de34 Author: Rafal Milecki Date: Fri Oct 2 03:54:44 2009 -0300 V4L/DVB (13116): gspca - ov519: Webcam 041e:4067 added. commit 518c8df77c21b7d1690dd8b96eb0e54c4ec1c9c1 upstream. Signed-off-by: Rafal Milecki Signed-off-by: Jean-Francois Moine Signed-off-by: Mauro Carvalho Chehab Cc: Surbhi Palande Signed-off-by: Greg Kroah-Hartman commit 62965d8347a071c72f4dae96e65be5fb68dd052f Author: Jan Kara Date: Tue Dec 1 16:53:06 2009 +0100 ext3: Fix data / filesystem corruption when write fails to copy data commit 68eb3db08344286733adac48304d9fb7a0e53b27 upstream. When ext3_write_begin fails after allocating some blocks or generic_perform_write fails to copy data to write, we truncate blocks already instantiated beyond i_size. Although these blocks were never inside i_size, we have to truncate pagecache of these blocks so that corresponding buffers get unmapped. Otherwise subsequent __block_prepare_write (called because we are retrying the write) will find the buffers mapped, not call ->get_block, and thus the page will be backed by already freed blocks leading to filesystem and data corruption. Reported-by: James Y Knight Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ad496b34c6835a89dd3a8f6c07dfcf8a0dd7c277 Author: Eric W. Biederman Date: Sun Dec 13 22:39:28 2009 -0800 net: Fix userspace RTM_NEWLINK notifications. commit d90a909e1f3e006a1d57fe11fd417173b6494701 upstream. I received some bug reports about userspace programs having problems because after RTM_NEWLINK was received they could not immeidate access files under /proc/sys/net/ because they had not been registered yet. The problem was trivailly fixed by moving the userspace notification from rtnetlink_event to the end of register_netdevice. Signed-off-by: Eric W. Biederman Cc: David Miller Signed-off-by: Greg Kroah-Hartman commit 383073d49fc78aa793c51018e29253c83410401e Author: Zhao Yakui Date: Fri Dec 11 15:17:20 2009 +0800 ACPI: Use the ARB_DISABLE for the CPU which model id is less than 0x0f. commit 03a05ed1152944000151d57b71000de287a1eb02 upstream. Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE. The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly. So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f. http://bugzilla.kernel.org/show_bug.cgi?id=14700 Signed-off-by: Zhao Yakui Acked-by: Venkatesh Pallipadi Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f0cc8412be0a164f9472f161dfd74fc1ca6ac284 Author: Tejun Heo Date: Thu Dec 10 08:43:16 2009 +0900 vmalloc: conditionalize build of pcpu_get_vm_areas() No matching upstream commit as it was resolved differently there. pcpu_get_vm_areas() is used only when dynamic percpu allocator is used by the architecture. In 2.6.32, ia64 doesn't use dynamic percpu allocator and has a macro which makes pcpu_get_vm_areas() buggy via local/global variable aliasing and triggers compile warning. The problem is fixed in upstream and ia64 uses dynamic percpu allocators, so the only left issue is inclusion of unnecessary code and compile warning on ia64 on 2.6.32. Don't build pcpu_get_vm_areas() if legacy percpu allocator is in use. Signed-off-by: Tejun Heo Reported-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit f996ff1a936f66ea00ecc760ab19e5f663579278 Author: Corentin Chary Date: Mon Dec 7 22:05:50 2009 +0100 asus-laptop: change light sens default values. commit d951d4cc84e8b5ddb8e0ab81cf6a72cc73fdd668 upstream. The light sensor disable brightness key and /sys/class/backlight/ control. There was a lot of report from users who didn't understand why they couldn't change their brightness, including: https://bugs.launchpad.net/bugs/222171 https://bugzilla.novell.com/show_bug.cgi?id=514747 http://bugzilla.kernel.org/show_bug.cgi?id=13671 http://bugzilla.kernel.org/show_bug.cgi?id=14432 Now the light sensor is disabled, and if the user want to enable it, the level should be ok. The funny thing is that comments where ok, not code. Cc: stable@kernel.org Cc: Thomas Renninger Cc: Peter Küppers Cc: Michael Franzl Cc: Ian Turner Signed-off-by: Corentin Chary Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 9bcfc6c08e4c9c29b24311307d7d4714572810ec Author: Peter Feuerer Date: Tue Nov 17 14:27:37 2009 -0800 acerhdf: add new BIOS versions commit 360657463679dee44f0b167ffa61f563b4fee101 upstream. Added new BIOS versions for following netbooks: Acer 1410, Gateway LT31, Packard Bell DOA150. As the Gateway LT31 machines have different register values for setting and checking the off-state, the "cmd_off" variable has been splitted up to "cmd_off" and "chk_off". Signed-off-by: Peter Feuerer Cc: Borislav Petkov Cc: Andreas Mohr Signed-off-by: Andrew Morton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 6088ca9288f87655ceac3bde1dbb921bf4ce5d86 Author: Alan Cox Date: Tue Dec 15 16:46:40 2009 -0800 matroxfb: fix problems with display stability commit 8c651311a3a08c1e4815de6933e00a760e498dae upstream. Regression caused in 2.6.23 and then despite repeated requests never fixed or dealt with (Petr promised to sort it in 2008 but seems to have forgotten). Enough is enough - remove the problem line that was added. If it upsets someone they've had two years to deal with it and at the very least it'll rattle their cage and wake them up. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709 Signed-off-by: Alan Cox Reported-by: Damon Tested-by: Ruud van Melick Cc: Petr Vandrovec Cc: Pekka Enberg Cc: Paul A. Clarke Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67f3bf7f5b9ae151ef227b31d343c677d1f9b789 Author: Zhu Yi Date: Wed Dec 2 14:24:37 2009 +0800 ipw2100: fix rebooting hang with driver loaded commit 52ce3e9a7db754b78cf2cbabc87013f921b25b28 upstream. Add PCI .shutdown method so that we can disable the device during shutdown or reboot. Without this, the reboot doesn't work well on some platforms. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2124 Tested-by: pablo Signed-off-by: Zhu Yi Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1794daecdb3e628cb1fcb8aee8d3ac30571aa753 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:22 2009 +0000 thinkpad-acpi: preserve rfkill state across suspend/resume commit 208b996b6c460285650d39b2330f8ef82c007d10 upstream. Since the rfkill rework in 2.6.31, the driver is always resuming with the radios disabled. Change thinkpad-acpi to ask the firmware to resume with the radios in the last state. This fixes the Bluetooth and WWAN rfkill switches. Note that it means we respect the firmware's oddities. Should the user toggle the hardware rfkill switch on and off, it might cause the radios to resume enabled. UWB is an unknown quantity since it has nowhere the same level of firmware support (no control over state storage in NVRAM, for example), and might need further fixing. Testers welcome. This change fixes a regression from 2.6.30. Reported-by: Jerone Young Reported-by: Ian Molton Signed-off-by: Henrique de Moraes Holschuh Tested-by: Ian Molton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 5279bfc6293bd98c3adaf94e5861e9001669c432 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:21 2009 +0000 thinkpad-acpi: fix default brightness_mode for R50e/R51 commit a9f8eacca4e9e8693de9b896c1fa7aadaa9402e8 upstream. According to a report, the R50e wants EC-based brightness control, even if it uses an Intel GPU. The current driver default was reported to not work at all. This bug can be worked around by the "brightness_mode=3" module parameter. Change the default of the R50e and R51 2xxx models (which use the same EC firmware, 1V) to TPACPI_BRGHT_Q_EC, but keep TPACPI_BRGHT_Q_ASK set for now, as I'd like to get more reports. This fixes a regression caused by commit 59fe4fe34d7afdf63208124f313be9056feaa2f4, "thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM" Kernel 2.6.31 also needs this fix. Reported-by: Ferenc Wagner Tested-by: Ferenc Wagner Signed-off-by: Henrique de Moraes Holschuh Cc: stable@kernel.org Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 3dac78c65b4c503199f1ef157e2934eea33425e8 Author: Kirill A. Shutemov Date: Tue Dec 15 16:47:01 2009 -0800 memcg: fix memory.memsw.usage_in_bytes for root cgroup commit cd9b45b78a61e8df250e69385c74e729e5b66abf upstream. A memory cgroup has a memory.memsw.usage_in_bytes file. It shows the sum of the usage of pages and swapents in the cgroup. Presently the root cgroup's memsw.usage_in_bytes shows the wrong value - the number of swapents are not added. So take MEM_CGROUP_STAT_SWAPOUT into account. Signed-off-by: Kirill A. Shutemov Reviewed-by: Daisuke Nishimura Acked-by: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e8d9252227536dc8bd4e2d254d16b5feef542496 Author: Li Peng Date: Wed Dec 16 16:33:25 2009 +0100 drm/i915: Fix sync to vblank when VGA output is turned off commit 778c902640530371a169ad1c03566e7c51b09874 upstream In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng Reviewed-by: Jesse Barnes [anholt: hand-applied for conflicts with overlay changes] Signed-off-by: Eric Anholt Cc: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 58cd74bafb36b884abe67998cdef4203ae01769f Author: Vivek Natarajan Date: Wed Dec 16 11:51:45 2009 -0500 mac80211: Fix dynamic power save for scanning. Upstream commit: 7c3f4bbedc241ddcd3abe1f419c356e625231da1 Not only ps_sdata but also IEEE80211_CONF_PS is to be considered before restoring PS in scan_ps_disable(). For instance, when ps_sdata is set but CONF_PS is not set just because the dynamic timer is still running, a sw scan leads to setting of CONF_PS in scan_ps_disable instead of restarting the dynamic PS timer. Also for the above case, a null data frame is to be sent after returning to operating channel which was not happening with the current implementation. This patch fixes this too. Signed-off-by: Vivek Natarajan Reviewed-by: Kalle Valo Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0f77b958dccf9d3b59d986ea160f84b50c646712 Author: Felix Fietkau Date: Wed Dec 16 11:51:44 2009 -0500 ath9k: fix tx status reporting This is a backport of upstream commit: e8c6342d989e241513baeba4b05a04b6b1f3bc8b This patch fixes a bug in ath9k's tx status check, which caused mac80211 to consider regularly transmitted unicast frames as un-acked. When checking the ts_status field for errors, it needs to be masked with ATH9K_TXERR_FILT, because this field also contains other fields like ATH9K_TX_ACKED. Without this patch, AP mode is pretty much unusable, as hostapd checks the ACK status for the frames that it injects. Signed-off-by: Felix Fietkau Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit e82a3a2db53b6df3a211c7b90c793d61fcb6ddae Author: Luis R. Rodriguez Date: Wed Dec 16 11:51:43 2009 -0500 ath9k: Fix maximum tx fifo settings for single stream devices This is a backport of upstream commit: f4709fdf683e1ed37b321c258b614ebe39752bf3 Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO buffer size of that of dual stream devices. Dual stream devices have a max PCU TX FIFO size of 8 KB while single stream devices have 4 KB. Single stream devices have an issue though and require hardware only to use half of the amount of its capable PCU TX FIFO size, 2 KB and this requires a change in software. Technically a change would not have been required (except for frame burst considerations of 128 bytes) if these devices would have been able to use the full 4 KB of the PCU TX FIFO size but our systems engineers recommend 2 KB to be used only. We enforce this through software by reducing the max frame triggger level to 2 KB. Fixing the max frame trigger level should then have a few benefits: * The PER will now be adjusted as designed for underruns when the max trigger level is reached. This should help alleviate the bus as the rate control algorithm chooses a slower rate which should ensure frames are transmitted properly under high system bus load. * The poll we use on our TX queues should now trigger and work as designed for single stream devices. The hardware passes data from each TX queue on the PCU TX FIFO queue respecting each queue's priority. The new trigger level ensures this seeding of the PCU TX FIFO queue occurs as designed which could mean avoiding false resets and actually reseting hw correctly when a TX queue is indeed stuck. * Some undocumented / unsupported behaviour could have been triggered when the max trigger level level was being set to 4 KB on single stream devices. Its not clear what this issue was to me yet. Cc: Kyungwan Nam Cc: Bennyam Malavazi Cc: Stephen Chen Cc: Shan Palanisamy Cc: Paul Shaw Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit 022fe0eb677b07aa37a3f88eab5ed47be2faffb5 Author: Luis R. Rodriguez Date: Wed Dec 16 11:51:42 2009 -0500 ath9k: fix processing of TX PS null data frames This is a backport of upstream commit: e7824a50662f7f79b1a739f705b4d906c31cf221 When mac80211 was telling us to go into Powersave we listened and immediately turned RX off. This meant hardware would not see the ACKs from the AP we're associated with and hardware we'd end up retransmiting the null data frame in a loop helplessly. Fix this by keeping track of the transmitted nullfunc frames and only when we are sure the AP has sent back an ACK do we go ahead and shut RX off. Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Vivek Natarajan Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit 978962f22c95c70f9018a9181c73525d26f0f3bd Author: Sujith Date: Wed Dec 16 11:51:41 2009 -0500 ath9k: Fix TX hang poll routine This is a backport of upstream commit: 332c556633b8c5fb4e890b1783122f2315526590 When TX is hung, the chip is reset. Ensure that the chip is awake by using the PS wrappers. Signed-off-by: Sujith Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit 7847a351aaaa21696dd07f412c493786b53a1999 Author: Johannes Berg Date: Fri Nov 13 23:40:09 2009 +0100 tracing: Fix event format export commit 811cb50baf63461ce0bdb234927046131fc7fa8b upstream. For some reason the export of the event print format to userspace uses '#fmt' which breaks if the format string is anything but a plain string, for example if it is built with macros then the macro names are exported instead of their contents. Use "\"%s\"", fmt instead of "%s", #fmt to export the string and not the way it is built. For example, in net/mac80211/driver-trace.h for the trace event drv_start there is: TP_printk( LOCAL_PR_FMT, LOCAL_PR_ARG ) Which use to produce: print fmt: LOCAL_PR_FMT, REC->wiphy_name Now produces: print fmt: "%s", REC->wiphy_name Signed-off-by: Johannes Berg LKML-Reference: <20091113224009.GB23942@elte.hu> Signed-off-by: Steven Rostedt Cc: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e75a313897fa83be86afb38a6e4415e923cdca80 Author: Larry Finger Date: Mon Nov 23 18:42:36 2009 -0600 b43legacy: avoid PPC fault during resume commit 316a4d966cae3c2dec83ebb1ee1a3515f97b30ff upstream. For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43legacy_status() returns a value of 2 (B43legacy_STAT_STARTED); however, one finds that the driver is unable to associate after resuming from hibernation unless this routine returns 1. To satisfy both conditions, the routine is rewritten to return TRUE whenever b43legacy_status() returns a value < 2. This patch fixes the second problem listed in the postings for Red Hat Bugzilla #538523. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 3263c617570ed7c7292ea484d1fdf31687d110ee Author: David S. Miller Date: Sat Dec 5 17:17:55 2009 -0800 sparc: Set UTS_MACHINE correctly. [ Upstream commit 7f5620a5fcd658f219e85831d3691908f1eccbde ] "ARCH" can be just about anything, so we shouldn't end up with UTS_MACHINE of "sparc" in a 64-bit kernel build just because someone set the personality using 'sparc32' or similar. CONFIG_SPARC64 drives the compilation and therefore provides the definitive value, not "ARCH". This mirrors commit 8c6531f7a99f29ba8817ffb12cc9ecf190049bd6 (x86: correctly set UTS_MACHINE for "make ARCH=x86") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ec683e0dc39688557189eed2153367d0acf61e2 Author: David S. Miller Date: Wed Dec 9 01:43:45 2009 -0800 sparc64: Fix stack debugging IRQ stack regression. [ Upstream commit 166e553a575f09485f6d0df8a1ef3c5991f7d953 ] Commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd (sparc64: Implement IRQ stacks.) has two bugs. First, the softirq range check forgets to subtract STACK_BIAS before comparing with %sp. Next, on failure the wrong label is jumped to, resulting in a bogus stack being loaded. Reported-by: Igor Kovalenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c141dab88c2afe8a1d43b64f55db11523cc4ec2d Author: David S. Miller Date: Wed Dec 9 01:39:09 2009 -0800 sparc64: Fix overly strict range type matching for PCI devices. [ Upstream commit 4230fa3b89ea1c413766bd411a8315a3d05aa6c7 ] When we are trying to see if a range property entry applies to a given address, we are overly strict about the type. We should only allow I/O ranges for I/O addresses, and only allow CONFIG space ranges for CONFIG space address. However for MEM ranges, they come in 32-bit and 64-bit flavors. And a lack of an exact match is OK if the range is 32-bit and the address is 64-bit. We can assign a 64-bit address properly into a 32-bit parent range just fine. So allow it. Reported-by: Patrick Finnegan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 257abc89a7765c57137811419caac5efca2e7b2d Author: David S. Miller Date: Wed Dec 9 23:44:43 2009 -0800 sparc64: Don't specify IRQF_SHARED for LDC interrupts. [ Upstream commit 08a036d583409e3517e3d15b7478d029b25f2cf2 ] IRQF_SHARED and IRQF_DISABLED don't mix. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 599343ebd4b057e35955915d73410ea0b987875a Author: Stanislav Brabec Date: Tue Dec 8 21:00:22 2009 -0800 b44 WOL setup: one-bit-off stack corruption kernel panic fix [ Upstream commit: e0188829cb724e7d12a2d4e343b368ff1d6e1471 ] About 50% of shutdowns of b44 Ethernet adapter ends by kernel panic with kernels compiled with stack-protector. Checking b44_magic_pattern() return values, one call of b44_magic_pattern() returns 127. It means, that set_bit(128, pmask) was called on line 1509. It means that bit 0 of 17th byte of pmask was overwritten. But pmask has only 16 bytes. Stack corruption happens. It seems that set_bit() on line 1509 always writes one bit off. The fix does not only solve the stack corruption, but also makes Wake On LAN working on my onboard B44 on Asus A7V-333X mainboard. It seems that this problem affects all kernel versions since commit 725ad800 ([PATCH] b44: add wol for old nic) on 2006-06-20. Signed-off-by: Stanislav Brabec Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 42d8bd7737a65b535d3247392b11fcd0f32303fe Author: Patrick McHardy Date: Tue Dec 1 15:53:57 2009 -0800 ip_fragment: also adjust skb->truesize for packets not owned by a socket [ Upstream commit b2722b1c3a893ec6021508da15b32282ec79f4da ] When a large packet gets reassembled by ip_defrag(), the head skb accounts for all the fragments in skb->truesize. If this packet is refragmented again, skb->truesize is not re-adjusted to reflect only the head size since its not owned by a socket. If the head fragment then gets recycled and reused for another received fragment, it might exceed the defragmentation limits due to its large truesize value. skb_recycle_check() explicitly checks for linear skbs, so any recycled skb should reflect its true size in skb->truesize. Change ip_fragment() to also adjust the truesize value of skbs not owned by a socket. Reported-and-tested-by: Ben Menchaca Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0d975c7ebdebbdf559100c0b09e037679062f052 Author: Damian Lukowski Date: Mon Dec 7 06:06:15 2009 +0000 tcp: Stalling connections: Fix timeout calculation routine [ Upstream commit 07f29bc5bbae4e53e982ab956fed7207990a7786 ] This patch fixes a problem in the TCP connection timeout calculation. Currently, timeout decisions are made on the basis of the current tcp_time_stamp and retrans_stamp, which is usually set at the first retransmission. However, if the retransmission fails in tcp_retransmit_skb(), retrans_stamp is not updated and remains zero. This leads to wrong decisions in retransmits_timed_out() if tcp_time_stamp is larger than the specified timeout, which is very likely. In this case, the TCP connection dies after the first attempted (and unsuccessful) retransmission. With this patch, tcp_skb_cb->when is used instead, when retrans_stamp is not available. This bug has been introduced together with retransmits_timed_out() in 2.6.32, as the number of retransmissions has been used for timeout decisions before. The corresponding commit was 6fa12c85031485dff38ce550c24f10da23b0adaa (Revert Backoff [v3]: Calculate TCP's connection close threshold as a time value.). Thanks to Ilpo Järvinen for code suggestions and Frederic Leroy for testing. Reported-by: Frederic Leroy Signed-off-by: Damian Lukowski Acked-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a02d9614bab2896760c01477162a5657e06be7ed Author: Bartlomiej Zolnierkiewicz Date: Mon Nov 30 08:55:18 2009 +0000 slc90e66: fix UDMA handling [ Upstream commit ee31527a02b0a8e1aa4a5e4084d2db5fa34737ed ] Fix checking of the currently programmed UDMA mode. Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sergei Shtylyov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 80b337ebf9ff4e06cd4185b31d8972193a985262 Author: Milan Broz Date: Thu Dec 10 23:51:57 2009 +0000 dm crypt: make wipe message also wipe essiv key commit 542da317668c35036e8471822a564b609d05af66 upstream. The "wipe key" message is used to wipe the volume key from memory temporarily, for example when suspending to RAM. But the initialisation vector in ESSIV mode is calculated from the hashed volume key, so the wipe message should wipe this IV key too and reinitialise it when the volume key is reinstated. This patch adds an IV wipe method called from a wipe message callback. ESSIV is then reinitialised using the init function added by the last patch. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 7d41627824496f9c69ab2da972a72521ebeebf7a Author: Milan Broz Date: Thu Dec 10 23:51:56 2009 +0000 dm crypt: separate essiv allocation from initialisation commit b95bf2d3d5a48b095bffe2a0cd8c40453cf59557 upstream. This patch separates the construction of IV from its initialisation. (For ESSIV it is a hash calculation based on volume key.) Constructor code now preallocates hash tfm and salt array and saves it in a private IV structure. The next patch requires this to reinitialise the wiped IV without reallocating memory when resuming a suspended device. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 8419ee8215942d6bf3814391730421a4897fc410 Author: Mikulas Patocka Date: Thu Dec 10 23:51:54 2009 +0000 dm snapshot: cope with chunk size larger than origin commit 8e87b9b81b3c370f7e53c1ab6e1c3519ef37a644 upstream. Under some special conditions the snapshot hash_size is calculated as zero. This patch instead sets a minimum value of 64, the same as for the pending exception table. rounddown_pow_of_two(0) is an undefined operation (it expands to shift by -1). init_exception_table with an argument of 0 would fail with -ENOMEM. The way to trigger the problem is to create a snapshot with a chunk size that is larger than the origin device. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 0bca4a5b78ad922624e9a76a7e86453f1fec7239 Author: Mikulas Patocka Date: Thu Dec 10 23:51:52 2009 +0000 dm: avoid _hash_lock deadlock commit 6076905b5ef39e0ea58db32583c9e0036c05e47b upstream. Fix a reported deadlock if there are still unprocessed multipath events on a device that is being removed. _hash_lock is held during dev_remove while trying to send the outstanding events. Sending the events requests the _hash_lock again in dm_copy_name_and_uuid. This patch introduces a separate lock around regions that modify the link to the hash table (dm_set_mdptr) or the name or uuid so that dm_copy_name_and_uuid no longer needs _hash_lock. Additionally, dm_copy_name_and_uuid can only be called if md exists so we can drop the dm_get() and dm_put() which can lead to a BUG() while md is being freed. The deadlock: #0 [ffff8106298dfb48] schedule at ffffffff80063035 #1 [ffff8106298dfc20] __down_read at ffffffff8006475d #2 [ffff8106298dfc60] dm_copy_name_and_uuid at ffffffff8824f740 #3 [ffff8106298dfc90] dm_send_uevents at ffffffff88252685 #4 [ffff8106298dfcd0] event_callback at ffffffff8824c678 #5 [ffff8106298dfd00] dm_table_event at ffffffff8824dd01 #6 [ffff8106298dfd10] __hash_remove at ffffffff882507ad #7 [ffff8106298dfd30] dev_remove at ffffffff88250865 #8 [ffff8106298dfd60] ctl_ioctl at ffffffff88250d80 #9 [ffff8106298dfee0] do_ioctl at ffffffff800418c4 #10 [ffff8106298dff00] vfs_ioctl at ffffffff8002fab9 #11 [ffff8106298dff40] sys_ioctl at ffffffff8004bdaf #12 [ffff8106298dff80] tracesys at ffffffff8005d28d (via system_call) Reported-by: guy keren Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit c22d66f16eaeec0d3c4df607f425f4ebf2b8d238 Author: Milan Broz Date: Thu Dec 10 23:51:56 2009 +0000 dm crypt: restructure essiv error path commit 5861f1be00b3b70f8ab5e5a81392a6cf69666cd2 upstream. Use kzfree for salt deallocation because it is derived from the volume key. Use a common error path in ESSIV constructor. Required by a later patch which fixes the way key material is wiped from memory. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit c7f27e82997f9c835b4c241d1f302501d0cdcc9e Author: Milan Broz Date: Thu Dec 10 23:51:55 2009 +0000 dm crypt: move private iv fields to structs commit 6047359277517c4e56d8bfd6ea4966d7a3924151 upstream. Define private structures for IV so it's easy to add further attributes in a following patch which fixes the way key material is wiped from memory. Also move ESSIV destructor and remove unnecessary 'status' operation. There are no functional changes in this patch. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 5f5d50a0f5530e5a6df52755c74ec5a47829f8cc Author: Mikulas Patocka Date: Thu Dec 10 23:51:53 2009 +0000 dm snapshot: only take lock for statustype info not table commit 94e76572b5dd37b1f0f4b3742ee8a565daead932 upstream. Take snapshot lock only for STATUSTYPE_INFO, not STATUSTYPE_TABLE. Commit 4c6fff445d7aa753957856278d4d93bcad6e2c14 (dm-snapshot-lock-snapshot-while-supplying-status.patch) introduced this use of the lock, but userspace applications using libdevmapper have been found to request STATUSTYPE_TABLE while the device is suspended and the lock is already held, leading to deadlock. Since the lock is not necessary in this case, don't try to take it. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 5db89cf4ea748e1c2d29d52175b2bace466078c7 Author: Julia Lawall Date: Thu Dec 10 23:51:52 2009 +0000 dm exception store: free tmp_store on persistent flag error commit 613978f8711c7fd4d0aa856872375d2abd7c92ff upstream. Error handling code following a kmalloc should free the allocated data. Signed-off-by: Julia Lawall Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 1e75ccef288b75a3b207c1b1be4baf5ae5ac0ffb Author: Ian Campbell Date: Fri Jun 5 11:58:37 2009 +0100 xen: try harder to balloon up under memory pressure. commit bc2c0303226ec716854d3c208c7f84fe7aa35cd7 upstream. Currently if the balloon driver is unable to increase the guest's reservation it assumes the failure was due to reaching its full allocation, gives up on the ballooning operation and records the limit it reached as the "hard limit". The driver will not try again until the target is set again (even to the same value). However it is possible that ballooning has in fact failed due to memory pressure in the host and therefore it is desirable to keep attempting to reach the target in case memory becomes available. The most likely scenario is that some guests are ballooning down while others are ballooning up and therefore there is temporary memory pressure while things stabilise. You would not expect a well behaved toolstack to ask a domain to balloon to more than its allocation nor would you expect it to deliberately over-commit memory by setting balloon targets which exceed the total host memory. This patch drops the concept of a hard limit and causes the balloon driver to retry increasing the reservation on a timer in the same manner as when decreasing the reservation. Also if we partially succeed in increasing the reservation (i.e. receive less pages than we asked for) then we may as well keep those pages rather than returning them to Xen. Signed-off-by: Ian Campbell Signed-off-by: Greg Kroah-Hartman commit 910965b03f3c8930db26378bd9ab06ea74b91bdb Author: Gianluca Guida Date: Thu Jul 30 22:54:36 2009 +0100 Xen balloon: fix totalram_pages counting. commit 3d65c9488cadd2f11bd4d60c7266e639ece5d0d6 upstream. Change totalram_pages when a single page is added/removed to the ballooned list. This avoid totalram_pages to be set erroneously to max_pfn at boot. Signed-off-by: Gianluca Guida Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 7a0eb0721ef8015e1d17fb1cc017179eedf8cc2c Author: Ian Campbell Date: Tue Dec 1 11:47:15 2009 +0000 xen: explicitly create/destroy stop_machine workqueues outside suspend/resume region. commit b4606f2165153833247823e8c04c5e88cb3d298b upstream. I have observed cases where the implicit stop_machine_destroy() done by stop_machine() hangs while destroying the workqueues, specifically in kthread_stop(). This seems to be because timer ticks are not restarted until after stop_machine() returns. Fortunately stop_machine provides a facility to pre-create/post-destroy the workqueues so use this to ensure that workqueues are only destroyed after everything is really up and running again. I only actually observed this failure with 2.6.30. It seems that newer kernels are somehow more robust against doing kthread_stop() without timer interrupts (I tried some backports of some likely looking candidates but did not track down the commit which added this robustness). However this change seems like a reasonable belt&braces thing to do. Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit ebe5f3b81f1d3677882b5b1c382321096c7d1851 Author: Jeremy Fitzhardinge Date: Wed Nov 25 13:15:38 2009 -0800 xen: use iret for return from 64b kernel to 32b usermode commit 6aaf5d633bb6cead81b396d861d7bae4b9a0ba7e upstream. If Xen wants to return to a 32b usermode with sysret it must use the right form. When using VCGF_in_syscall to trigger this, it looks at the code segment and does a 32b sysret if it is FLAT_USER_CS32. However, this is different from __USER32_CS, so it fails to return properly if we use the normal Linux segment. So avoid the whole mess by dropping VCGF_in_syscall and simply use plain iret to return to usermode. Signed-off-by: Jeremy Fitzhardinge Acked-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 98a0174b42a81685c342a230a8a8755a9df9bcd6 Author: Ian Campbell Date: Tue Dec 1 16:15:30 2009 +0000 xen: don't leak IRQs over suspend/resume. commit fed5ea87e02aaf902ff38c65b4514233db03dc09 upstream. On resume irq_info[*].evtchn is reset to 0 since event channel mappings are not preserved over suspend/resume. The other contents of irq_info is preserved to allow rebind_evtchn_irq() to function. However when a device resumes it will try to unbind from the previous IRQ (e.g. blkfront goes blkfront_resume() -> blkif_free() -> unbind_from_irqhandler() -> unbind_from_irq()). This will fail due to the check for VALID_EVTCHN in unbind_from_irq() and the IRQ is leaked. The device will then continue to resume and allocate a new IRQ, eventually leading to find_unbound_irq() panic()ing. Fix this by changing unbind_from_irq() to handle teardown of interrupts which have type!=IRQT_UNBOUND but are not currently bound to a specific event channel. Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit f180b871d6cbcaaf9349075afb515081de073acb Author: Ian Campbell Date: Tue Dec 1 11:47:14 2009 +0000 xen: improve error handling in do_suspend. commit 65f63384b391bf4d384327d8a7c6de9860290b5c upstream. The existing error handling has a few issues: - If freeze_processes() fails it exits with shutting_down = SHUTDOWN_SUSPEND. - If dpm_suspend_noirq() fails it exits without resuming xenbus. - If stop_machine() fails it exits without resuming xenbus or calling dpm_resume_end(). - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not nested in the obvious way. Fix by ensuring each failure case goto's the correct label. Treat a failure of stop_machine() as a cancelled suspend in order to follow the correct resume path. Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 0bf7bb9861a419c63055293ddec67329165f8d84 Author: Ian Campbell Date: Wed Nov 25 14:12:08 2009 +0000 xen: call clock resume notifier on all CPUs commit f6eafe3665bcc374c66775d58312d1c06c55303f upstream. tick_resume() is never called on secondary processors. Presumably this is because they are offlined for suspend on native and so this is normally taken care of in the CPU onlining path. Under Xen we keep all CPUs online over a suspend. This patch papers over the issue for me but I will investigate a more generic, less hacky, way of doing to the same. tick_suspend is also only called on the boot CPU which I presume should be fixed too. Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Cc: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit c7092102563af5c81bd8d08582fdbe4529cbcf17 Author: Jeremy Fitzhardinge Date: Tue Nov 24 09:38:25 2009 -0800 xen: register runstate info for boot CPU early commit 499d19b82b586aef18727b9ae1437f8f37b66e91 upstream. printk timestamping uses sched_clock, which in turn relies on runstate info under Xen. So make sure we set it up before any printks can be called. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 8fd7520c678cc3d8af422bca9f22149731520f1b Author: Jeremy Fitzhardinge Date: Tue Nov 24 09:58:49 2009 -0800 xen: don't call dpm_resume_noirq() with interrupts disabled. commit 922cc38ab71d1360978e65207e4a4f4988987127 upstream. dpm_resume_noirq() takes a mutex, so it can't be called from a no-interrupt context. Don't call it from within the stop-machine function, but just afterwards, since we're resuming anyway, regardless of what happened. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 25fa3416973b064c4a156340301a5b97301af602 Author: Ian Campbell Date: Tue Nov 24 09:32:48 2009 -0800 xen: register runstate on secondary CPUs commit 028896721ac04f6fa0697f3ecac3f98761746363 upstream. The commit "xen: re-register runstate area earlier on resume" caused us to never try and setup the runstate area for secondary CPUs. Ensure that we do this... Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit d7b1aedc1a241dcde39a8a35757b6b0797eac5ff Author: Ian Campbell Date: Tue Nov 24 10:16:23 2009 +0000 xen: register timer interrupt with IRQF_TIMER commit f350c7922faad3397c98c81a9e5658f5a1ef0214 upstream. Otherwise the timer is disabled by dpm_suspend_noirq() which in turn prevents correct operation of stop_machine on multi-processor systems and breaks suspend. Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit b6172e046931fd39a53b3607af40155eadbbecc2 Author: Ian Campbell Date: Sat Nov 21 11:32:49 2009 +0000 xen: correctly restore pfn_to_mfn_list_list after resume commit fa24ba62ea2869308ffc9f0b286ac9650b4ca6cb upstream. pvops kernels >= 2.6.30 can currently only be saved and restored once. The second attempt to save results in: ERROR Internal error: Frame# in pfn-to-mfn frame list is not in pseudophys ERROR Internal error: entry 0: p2m_frame_list[0] is 0xf2c2c2c2, max 0x120000 ERROR Internal error: Failed to map/save the p2m frame list I finally narrowed it down to: commit cdaead6b4e657f960d6d6f9f380e7dfeedc6a09b Author: Jeremy Fitzhardinge Date: Fri Feb 27 15:34:59 2009 -0800 xen: split construction of p2m mfn tables from registration Build the p2m_mfn_list_list early with the rest of the p2m table, but register it later when the real shared_info structure is in place. Signed-off-by: Jeremy Fitzhardinge The unforeseen side-effect of this change was to cause the mfn list list to not be rebuilt on resume. Prior to this change it would have been rebuilt via xen_post_suspend() -> xen_setup_shared_info() -> xen_setup_mfn_list_list(). Fix by explicitly calling xen_build_mfn_list_list() from xen_post_suspend(). Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit b6c73e8a66cd9f54bfc0d2267afd10eaf44157e1 Author: Jeremy Fitzhardinge Date: Sat Nov 21 08:46:29 2009 +0800 xen: restore runstate_info even if !have_vcpu_info_placement commit 3905bb2aa7bb801b31946b37a4635ebac4009051 upstream. Even if have_vcpu_info_placement is not set, we still need to set up the runstate area on each resumed vcpu. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit e27d65dec237be523c3e3c8b193007243367aad9 Author: Ian Campbell Date: Sat Nov 21 08:35:55 2009 +0800 xen: re-register runstate area earlier on resume. commit be012920ecba161ad20303a3f6d9e96c58cf97c7 upstream. This is necessary to ensure the runstate area is available to xen_sched_clock before any calls to printk which will require it in order to provide a timestamp. I chose to pull the xen_setup_runstate_info out of xen_time_init into the caller in order to maintain parity with calling xen_setup_runstate_info separately from calling xen_time_resume. Signed-off-by: Ian Campbell Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit fd28fac739e3a2e2be8138fb10ce554f74a50cae Author: Jeremy Fitzhardinge Date: Tue Nov 24 16:41:47 2009 -0800 xen/xenbus: make DEVICE_ATTR()s static commit db05fed0ad72f264e39bcb366795f7367384ec92 upstream. They don't need to be global, and may cause linker clashes. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 14173dbee479f3c9560f303040488505d7ae5381 Author: Zhao Yakui Date: Wed Dec 2 10:03:33 2009 +0800 drm/i915: Add the missing clonemask for display port on Ironlake commit 652af9d74e1a3a10bb10f0d8e8f42ddac26bbc1a upstream. Add the missing clonemask for display port on Ironlake. Signed-off-by: Zhao Yakui Reviewed-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 739f9e4f0c9ede0209e874ed223b297d04483358 Author: Chris Wilson Date: Wed Dec 2 15:15:30 2009 +0000 drm/i915: Set the error code after failing to insert new offset into mm ht. commit 5618ca6abc2d6f475b258badc017a5254cf43d1b upstream. Signed-off-by: Chris Wilson Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 4a6ab40474d859a218e326550c2192f384527f81 Author: Martin Michlmayr Date: Thu Nov 19 16:29:45 2009 +0000 drm/ttm: Fix build failure due to missing struct page commit c3a73ba13bac7fd96030f39202b2d37fb19c46a6 upstream. drm/ttm fails to build on MIPS because "struct page" is not known: | In file included from drivers/gpu/drm/ttm/ttm_memory.c:28: | include/drm/ttm/ttm_memory.h:154: warning: 'struct page' declared inside parameter list | include/drm/ttm/ttm_memory.h:154: warning: its scope is only this definition or declaration, which is probably not what you want | include/drm/ttm/ttm_memory.h:156: warning: 'struct page' declared inside parameter list | drivers/gpu/drm/ttm/ttm_memory.c:540: error: conflicting types for 'ttm_mem_global_alloc_page' | include/drm/ttm/ttm_memory.h:154: error: previous declaration of 'ttm_mem_global_alloc_page' was here | drivers/gpu/drm/ttm/ttm_memory.c:561: error: conflicting types for 'ttm_mem_global_free_page' | include/drm/ttm/ttm_memory.h:156: error: previous declaration of 'ttm_mem_global_free_page' was here Signed-off-by: Martin Michlmayr Acked-by: Thomas Hellstrom Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e582ed67311ec17b343f21b82fc40de4d35fff3e Author: Alex Deucher Date: Thu Dec 3 16:28:02 2009 -0500 drm/radeon/kms: rs6xx/rs740: clamp vram to aperture size commit 0088dbdb809e8799cb8f26da5ac64b15201fa99d upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 3234b70ff908ed6479481027456fdd9826f56937 Author: Alex Deucher Date: Thu Dec 3 16:18:19 2009 -0500 drm/radeon/kms: fix vram setup on rs600 commit 722f29434e72188b2d20f9b41f4b5952073ed568 upstream. also fix up rs690 mem width. should fix fdo bug 25408 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 48198675919e94a9a8d5185a8312789eae2ea9a0 Author: Alex Deucher Date: Thu Dec 3 12:15:54 2009 -0500 drm/radeon/kms: fix legacy crtc2 dpms commit 8de21525439e6b5bb8d8c81e49094d867bf82f6d upstream. noticed by Matthijs Kooijman on fdo bug 22140 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 373b9483b6b1cc9ec21080ba29c90e9968102aa8 Author: Alex Deucher Date: Wed Dec 2 11:46:52 2009 -0500 drm/radeon/kms: handle vblanks properly with dpms on commit 500b758725314ab1b5316eb0caa5b0fa26740e6b upstream. avivo chips Copied from pre-avivo code. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5c5c0d7335f6cc65a7f18b09e473c346d20edc83 Author: Alex Deucher Date: Tue Dec 1 14:49:50 2009 -0500 drm/radeon/kms: Add quirk for HIS X1300 board commit 4e3f9b78ff917cc5c833858fdb5d96bc262e0bf3 upstream. Board is DVI+VGA, not DVI+DVI Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 49e6aacefc4ba11f7515391659a6e2f316a6e1ae Author: Benjamin Herrenschmidt Date: Tue Dec 8 18:45:45 2009 +0000 powerpc: Fix usage of 64-bit instruction in 32-bit altivec code commit e090aa80321b64c3b793f3b047e31ecf1af9538d upstream. e821ea70f3b4873b50056a1e0f74befed1014c09 introduced a bug by copying some 64-bit originated code as-is to be used by both 32 and 64-bit but this code contains a 64-bit ony "cmpdi" instruction. This changes it to cmpwi, which is fine since VRSAVE can only contains a 32-bit value anyway. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 6b3f68aeeae30d18186a844c92bf3269e3226f51 Author: Darrick J. Wong Date: Thu Dec 3 16:19:59 2009 +0000 powerpc/therm_adt746x: Record pwm invert bit at module load time] commit 1496e89ae2a0962748e55165a590fa3209c6f158 upstream. In commit 0512a9a8e277a9de2820211eef964473b714ae65, we unilaterally zero the "pwm invert" bit in the fan behavior configuration register. On my PowerBook G4, this results in the fans going to full speed at low temperature and shutting off at high temperature because the pwm invert bit is supposed to be set. Therefore, record the pwm invert bit at driver load time, and write the bit into the fan behavior control register. This restores correct behavior on my PBG4 and should work around the bit being set to the wrong value after suspend/resume (which is what the original patch was trying to fix). It also fixes a minor omission where the pwm invert bit correction is NOT performed when switching into automatic mode. Signed-off-by: Darrick J. Wong Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d5f60d19405b2b8c338be1c70f013d39a40d049d Author: Bolko Maass Date: Fri Nov 27 05:44:33 2009 +0000 powerpc/windfarm: Add detection for second cpu pump commit 529586dc39b0ec47c6290c4e7bed6ea3ffd1d8fb upstream. Windfarm SMU control is explicitly missing support for a second CPU pump in G5 PowerMacs. Such machines actually exist (specifically Quads with a second pump), so this patch adds detection for it. Signed-off by: Bolko Maass Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 0a0fa09874289cbfce7e94bc1b61b57e7751a63f Author: Naoya Horiguchi Date: Mon Dec 14 17:59:59 2009 -0800 mm: hugetlb: fix hugepage memory leak in walk_page_range() commit d33b9f45bd24a6391bc05e2b5a13c1b5787ca9c2 upstream. Most callers of pmd_none_or_clear_bad() check whether the target page is in a hugepage or not, but walk_page_range() do not check it. So if we read /proc/pid/pagemap for the hugepage on x86 machine, the hugepage memory is leaked as shown below. This patch fixes it. Details ======= My test program (leak_pagemap) works as follows: - creat() and mmap() a file on hugetlbfs (file size is 200MB == 100 hugepages,) - read()/write() something on it, - call page-types with option -p (walk around the page tables), - munmap() and unlink() the file on hugetlbfs Without my patches ------------------ $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_pagemap [snip output] $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 900 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs/ $ 100 hugepages are accounted as used while there is no file on hugetlbfs. With my patches --------------- $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_pagemap [snip output] $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs $ No memory leaks. Signed-off-by: Naoya Horiguchi Cc: Andi Kleen Cc: Wu Fengguang Cc: Hugh Dickins Cc: Mel Gorman Cc: Lee Schermerhorn Cc: Andy Whitcroft Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 23022aab1a90cc3117b3816c79aea3977bce09ff Author: Naoya Horiguchi Date: Mon Dec 14 17:59:58 2009 -0800 mm: hugetlb: fix hugepage memory leak in mincore() commit 4f16fc107d9c9b8a72aa19b189a9216e90a7aaef upstream. Most callers of pmd_none_or_clear_bad() check whether the target page is in a hugepage or not, but mincore() and walk_page_range() do not check it. So if we use mincore() on a hugepage on x86 machine, the hugepage memory is leaked as shown below. This patch fixes it by extending mincore() system call to support hugepages. Details ======= My test program (leak_mincore) works as follows: - creat() and mmap() a file on hugetlbfs (file size is 200MB == 100 hugepages,) - read()/write() something on it, - call mincore() for first ten pages and printf() the values of *vec - munmap() and unlink() the file on hugetlbfs Without my patch ---------------- $ cat /proc/meminfo| grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_mincore vec[0] 0 vec[1] 0 vec[2] 0 vec[3] 0 vec[4] 0 vec[5] 0 vec[6] 0 vec[7] 0 vec[8] 0 vec[9] 0 $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 999 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs/ $ Return values in *vec from mincore() are set to 0, while the hugepage should be in memory, and 1 hugepage is still accounted as used while there is no file on hugetlbfs. With my patch ------------- $ cat /proc/meminfo| grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ./leak_mincore vec[0] 1 vec[1] 1 vec[2] 1 vec[3] 1 vec[4] 1 vec[5] 1 vec[6] 1 vec[7] 1 vec[8] 1 vec[9] 1 $ cat /proc/meminfo |grep "HugePage" HugePages_Total: 1000 HugePages_Free: 1000 HugePages_Rsvd: 0 HugePages_Surp: 0 $ ls /hugetlbfs/ $ Return value in *vec set to 1 and no memory leaks. [akpm@linux-foundation.org: cleanup] [akpm@linux-foundation.org: build fix] Signed-off-by: Naoya Horiguchi Cc: Andi Kleen Cc: Wu Fengguang Cc: Hugh Dickins Cc: Mel Gorman Cc: Lee Schermerhorn Cc: Andy Whitcroft Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b3e1b060b2a4079723332d9d98a5891d670b9f8e Author: Thomas Gleixner Date: Mon Dec 7 12:59:46 2009 +0100 x86: Fix bogus warning in apic_noop.apic_write() commit a946d8f11f0da9cfc714248036fcfd3a794d1e27 upstream. apic_noop is used to provide dummy apic functions. It's installed when the CPU has no APIC or when the APIC is disabled on the kernel command line. The apic_noop implementation of apic_write() warns when the CPU has an APIC or when the APIC is not disabled. That's bogus. The warning should only happen when the CPU has an APIC _AND_ the APIC is not disabled. apic_noop.apic_read() has the correct check. Signed-off-by: Thomas Gleixner Cc: Cyrill Gorcunov LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7fd943643cc5aef6546ca3d8914e01d4298ee769 Author: Larry Finger Date: Sat Dec 5 19:25:22 2009 -0600 rtl8187: Fix wrong rfkill switch mask for some models commit 70d57139f932b9ca21026253d02af71cf53d764a upstream. There are different bits used to convey the setting of the rfkill switch to the driver. The current driver only supports one of these possibilities. These changes were derived from the latest version of the vendor driver. This patch fixes the regression noted in kernel Bugzilla #14743. Signed-off-by: Larry Finger Reported-and-tested-by: Antti Kaijanmäki Tested-by: Hin-Tak Leung Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8cf6359fa10996157bd8030b572ac6050dff2580 Author: John W. Linville Date: Tue Dec 8 17:10:13 2009 -0500 wireless: correctly report signal value for IEEE80211_HW_SIGNAL_UNSPEC commit 19deffbeba930030cfaf000b920333c6ba99ad52 upstream. This part was missed in "cfg80211: implement get_wireless_stats", probably because sta_set_sinfo already existed and was only handling dBm signals. Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 22731c4b03371594e3bfdf032a64ee3cc6e61365 Author: Johannes Berg Date: Sat Oct 31 07:44:08 2009 +0100 mac80211: fix scan abort sanity checks commit 6d3560d4fc9c5b9fe1a07a63926ea70512c69c32 upstream. Since sometimes mac80211 queues up a scan request to only act on it later, it must be allowed to (internally) cancel a not-yet-running scan, e.g. when the interface is taken down. This condition was missing since we always checked only the local->scanning variable which isn't yet set in that situation. Reported-by: Luis R. Rodriguez Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c04c99abc6754fa92d428915ac4215994fe95609 Author: Javier Cardona Date: Wed Dec 9 18:43:01 2009 -0800 mac80211: Revert 'Use correct sign for mesh active path refresh' commit 7b324d28a94dac5a451e8cba66e8d324601e5b9a upstream. The patch ("mac80211: Use correct sign for mesh active path refresh.") was actually a bug. Reverted it and improved the explanation of how mesh path refresh works. Signed-off-by: Javier Cardona Signed-off-by: Andrey Yurovsky Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dde24b6c58b10e27c296f2d343e9512ec0dce874 Author: Javier Cardona Date: Wed Dec 9 18:43:00 2009 -0800 mac80211: Fixed bug in mesh portal paths commit 5d618cb81aeea19879975cd1f9a1e707694dfd7c upstream. Paths to mesh portals were being timed out immediately after each use in intermediate forwarding nodes. mppath->exp_time is set to the expiration time so assigning it to jiffies was marking the path as expired. Signed-off-by: Javier Cardona Signed-off-by: Andrey Yurovsky Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit fb0f7048cfa072125c98dc11884a96d1e03c0f9a Author: Vasanthakumar Thiagarajan Date: Fri Dec 4 17:41:34 2009 +0530 mac80211: Fix bug in computing crc over dynamic IEs in beacon commit 1814077fd12a9cdf478c10076e9c42094e9d9250 upstream. On a 32-bit machine, BIT() macro does not give the required bit value if the bit is mroe than 31. In ieee802_11_parse_elems_crc(), BIT() is suppossed to get the bit value more than 31 (42 (id of ERP_INFO_IE), 37 (CHANNEL_SWITCH_IE), (42), 32 (POWER_CONSTRAINT_IE), 45 (HT_CAP_IE), 61 (HT_INFO_IE)). As we do not get the required bit value for the above IEs, crc over these IEs are never calculated, so any dynamic change in these IEs after the association is not really handled on 32-bit platforms. This patch fixes this issue. Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a4b8b8eb2533da448fcaaef2467a1cc4489057b9 Author: Ian Jackson Date: Wed Nov 18 11:08:11 2009 +0100 Serial: Do not read IIR in serial8250_start_tx when UART_BUG_TXEN commit 68cb4f8e246bbbc649980be0628cae9265870a91 upstream. Do not read IIR in serial8250_start_tx when UART_BUG_TXEN Reading the IIR clears some oustanding interrupts so it is not safe. Instead, simply transmit immediately if the buffer is empty without regard to IIR. Signed-off-by: Ian Jackson Reviewed-by: Markus Armbruster Reviewed-by: Jiri Kosina Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit fa8e26457e28606446f9afd6566cead9d0418b73 Author: Alan Stern Date: Fri Dec 4 11:06:57 2009 -0500 Driver core: fix race in dev_driver_string commit 3589972e51fac1e02d0aaa576fa47f568cb94d40 upstream. This patch (as1310) works around a race in dev_driver_string(). If the device is unbound while the function is running, dev->driver might become NULL after we test it and before we dereference it. Signed-off-by: Alan Stern Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 9f2813ec1f4868d07d8a16f4a9c4932819fc5d8e Author: Mathieu Desnoyers Date: Tue Nov 17 14:40:26 2009 -0800 debugfs: fix create mutex racy fops and private data commit d3a3b0adad0865c12e39b712ca89efbd0a3a0dbc upstream. Setting fops and private data outside of the mutex at debugfs file creation introduces a race where the files can be opened with the wrong file operations and private data. It is easy to trigger with a process waiting on file creation notification. Signed-off-by: Mathieu Desnoyers Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5451f13711a2af1fffdfe0d1e2faf02449fdab28 Author: Sukadev Bhattiprolu Date: Tue Nov 17 18:35:43 2009 -0800 devpts_get_tty() should validate inode commit edfacdd6f81119b9005615593f2cbd94b8c7e2d8 upstream. devpts_get_tty() assumes that the inode passed in is associated with a valid pty. But if the only reference to the pty is via a bind-mount, the inode passed to devpts_get_tty() while valid, would refer to a pty that no longer exists. With a lot of debug effort, Grzegorz Nosek developed a small program (see below) to reproduce a crash on recent kernels. This crash is a regression introduced by the commit: commit 527b3e4773628b30d03323a2cb5fb0d84441990f Author: Sukadev Bhattiprolu Date: Mon Oct 13 10:43:08 2008 +0100 To fix, ensure that the dentry associated with the inode has not yet been deleted/unhashed by devpts_pty_kill(). See also: https://lists.linux-foundation.org/pipermail/containers/2009-July/019273.html tty-bug.c: #define _GNU_SOURCE #include #include #include #include #include #include #include #include void dummy(int sig) { } static int child(void *unused) { int fd; signal(SIGINT, dummy); signal(SIGHUP, dummy); pause(); /* cheesy synchronisation to wait for /dev/pts/0 to appear */ mount("/dev/pts/0", "/dev/console", NULL, MS_BIND, NULL); sleep(2); fd = open("/dev/console", O_RDWR); dup(0); dup(0); write(1, "Hello world!\n", sizeof("Hello world!\n")-1); return 0; } int main(void) { pid_t pid; char *stack; stack = malloc(16384); pid = clone(child, stack+16384, CLONE_NEWNS|SIGCHLD, NULL); open("/dev/ptmx", O_RDWR|O_NOCTTY|O_NONBLOCK); unlockpt(fd); grantpt(fd); sleep(2); kill(pid, SIGHUP); sleep(1); return 0; /* exit before child opens /dev/console */ } Reported-by: Grzegorz Nosek Signed-off-by: Sukadev Bhattiprolu Tested-by: Serge Hallyn Signed-off-by: Greg Kroah-Hartman commit bb2fb5d6a16840cf98af1a5d405a583c200d87a8 Author: Andi Kleen Date: Tue Dec 8 13:19:42 2009 +0100 futex: Take mmap_sem for get_user_pages in fault_in_user_writeable commit 722d0172377a5697919b9f7e5beb95165b1dec4e upstream. get_user_pages() must be called with mmap_sem held. Signed-off-by: Andi Kleen Cc: Andrew Morton Cc: Nick Piggin Cc: Darren Hart Cc: Peter Zijlstra LKML-Reference: <20091208121942.GA21298@basil.fritz.box> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit f1416ea0278b4bb6629d160e81e61ef8b6bffb4a Author: NeilBrown Date: Mon Dec 14 12:49:46 2009 +1100 md/bitmap: protect against bitmap removal while being updated. commit aa5cbd103887011b4830355f88fb055f9ad2d556 upstream. A write intent bitmap can be removed from an array while the array is active. When this happens, all IO is suspended and flushed before the bitmap is removed. However it is possible that bitmap_daemon_work is still running to clear old bits from the bitmap. If it is, it can dereference the bitmap after it has been freed. So introduce a new mutex to protect bitmap_daemon_work and get it before destroying a bitmap. This is suitable for any current -stable kernel. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit e4f676cea796e170fcd8561c8e2a234724d05f35 Author: Trond Myklebust Date: Thu Dec 10 09:05:55 2009 -0500 NFS: Fix nfs_migrate_page() commit 190f38e5cedc910940b1da9015f00458c18f97b4 upstream. The call to migrate_page() will cause the page->private field to be cleared. Also fix up the locking around the page->private transfer, so that we ensure that calls to nfs_page_find_request() don't end up racing. Finally, fix up a double free bug: nfs_unlock_request() already calls nfs_release_request() for us... Reported-by: Wu Fengguang Tested-by: Andi Kleen Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit b9058d460800ee672e90d09f7419117baa64f045 Author: Roel Kluin Date: Tue Dec 8 13:13:03 2009 -0500 SUNRPC: IS_ERR/PTR_ERR confusion commit 480e3243df156e39eea6c91057e2ae612a6bbe19 upstream. IS_ERR returns 1 or 0, PTR_ERR returns the error value. Signed-off-by: Roel Kluin Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 037b7867ec53baa0dea5d05d4201e4fbf2405fc3 Author: Amerigo Wang Date: Mon Dec 14 17:57:37 2009 -0800 hfs: fix a potential buffer overflow commit ec81aecb29668ad71f699f4e7b96ec46691895b6 upstream. A specially-crafted Hierarchical File System (HFS) filesystem could cause a buffer overflow to occur in a process's kernel stack during a memcpy() call within the hfs_bnode_read() function (at fs/hfs/bnode.c:24). The attacker can provide the source buffer and length, and the destination buffer is a local variable of a fixed length. This local variable (passed as "&entry" from fs/hfs/dir.c:112 and allocated on line 60) is stored in the stack frame of hfs_bnode_read()'s caller, which is hfs_readdir(). Because the hfs_readdir() function executes upon any attempt to read a directory on the filesystem, it gets called whenever a user attempts to inspect any filesystem contents. [amwang@redhat.com: modify this patch and fix coding style problems] Signed-off-by: WANG Cong Cc: Eugene Teo Cc: Roman Zippel Cc: Al Viro Cc: Christoph Hellwig Cc: Alexey Dobriyan Cc: Dave Anderson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 08d05bad84c4cc91a92ac9aa8c3106610cc0584b Author: Igor Grinberg Date: Sun Dec 6 15:45:43 2009 +0200 pxa/em-x270: fix usb hub power up/reset sequence commit 1b82e4c32fba96d8805b1e2126ba5382e56fac32 upstream. Signed-off-by: Igor Grinberg Signed-off-by: Mike Rapoport Signed-off-by: Eric Miao Signed-off-by: Greg Kroah-Hartman commit 61039163321943e3279b89f18e7662e5e596c3d9 Author: Russ Dill Date: Mon Dec 14 21:45:35 2009 -0700 USB: Close usb_find_interface race v3 commit c2d284ee04ab6f6718de2ddcf1b43160e046c41d upstream. USB drivers that create character devices call usb_register_dev in their probe function. This associates the usb_interface device with that minor number and creates the character device and announces it to the world. However, the driver's probe function is called before the new usb_interface is added to the driver's klist_devices. This is a problem because userspace will respond to the character device creation announcement by opening the character device. The driver's open function will the call usb_find_interface to find the usb_interface associated with that minor number. usb_find_interface will walk the driver's list of devices and find the usb_interface with the matching minor number. Because the announcement happens before the usb_interface is added to the driver's klist_devices, a race condition exists. A straightforward fix is to walk the list of devices on usb_bus_type instead since the device is added to that list before the announcement occurs. bus_find_device calls get_device to bump the reference count on the found device. It is arguable that the reference count should be dropped by the caller of usb_find_interface instead of usb_find_interface, however, the current users of usb_find_interface do not expect this. The original version of this patch only matched against minor number instead of driver and minor number. This version matches against both. Signed-off-by: Russ Dill Signed-off-by: Greg Kroah-Hartman commit 3d5536bccf57b761f41f0ac1d7453e9997b4fdbf Author: Alan Stern Date: Mon Dec 7 16:39:16 2009 -0500 USB: usb-storage: add BAD_SENSE flag commit a0bb108112a872c0b0c4b3ef4974f95fb75b155d upstream. This patch (as1311) fixes a problem in usb-storage: Some devices are pretty broken when it comes to reporting sense data. The information they send back indicates that they have more than 18 bytes of sense data available, but when the system asks for more than 18 they fail or hang. The symptom is that probing fails with multiple resets. The patch adds a new BAD_SENSE flag to indicate that usb-storage should never ask for more than 18 bytes of sense data. The flag can be set in an unusual_devs entry or via the "quirks=" module parameter, and it is set automatically whenever a REQUEST SENSE command for more than 18 bytes fails or times out. An unusual_devs entry is added for the Agfa photo frame, which uses a Prolific chip having this bug. Signed-off-by: Alan Stern Tested-by: Daniel Kukula Signed-off-by: Greg Kroah-Hartman commit f4c0cf18d2b21dd614662c3b95ce0ffd0a4aa881 Author: Andre Herms Date: Thu Nov 19 18:14:49 2009 +0100 USB: usbtmc: repeat usb_bulk_msg until whole message is transfered commit ec412b92dbe3ea839716853eea058d1bcc5e6ca4 upstream. usb_bulk_msg() transfers only bytes up to the maximum packet size. It must be repeated by the usbtmc driver until all bytes of a TMC message are transfered. Without this patch, ETIMEDOUT is reported when writing TMC messages larger than the maximum USB bulk size and the transfer remains incomplete. The user will notice that the device hangs and must be reset by either closing the application or pulling the plug. Signed-off-by: Andre Herms Signed-off-by: Greg Kroah-Hartman commit fdc28ded337a4eab23e4326924686f127d7a9cf8 Author: Zhang Le Date: Tue Nov 17 14:53:42 2009 -0800 USB: option.c: add support for D-Link DWM-162-U5 commit 54a8e144acad6506920f385f4ef2779664f05b21 upstream. Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device has 4 interfaces, of which 1 is handled by storage and the other 3 by option driver. The device appears first as CD-only 05c6:2100 device and must be switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch. The MessageContent for usb_modeswitch.conf is: "55534243e0c26a85000000000000061b000000020000000000000000000000" Signed-off-by: Zhang Le Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d25997311e1bf8c338db97558666b7642919b820 Author: Sergei Shtylyov Date: Mon Nov 16 16:24:05 2009 +0530 USB: musb_gadget_ep0: fix unhandled endpoint 0 IRQs, again commit 196f1b7a387546f425df2f1fad26772e3d513aea upstream. Commit a5073b52833e4df8e16c93dc4cbb7e0c558c74a2 (musb_gadget: fix unhandled endpoint 0 IRQs) somehow missed its key change: "The gadget EP0 code routinely ignores an interrupt at end of the data phase because of musb_g_ep0_giveback() resetting the state machine to "idle, waiting for SETUP" phase prematurely." So, the majority of the cases of unhandled IRQs is still unfixed... Signed-off-by: Sergei Shtylyov Signed-off-by: Anand Gadiyar Signed-off-by: Greg Kroah-Hartman commit 7f0d909acd1644a1eb313c7f67f17f9aa58c9ac6 Author: Sarah Sharp Date: Tue Dec 1 10:37:07 2009 -0800 USB: xhci: Add correct email and files to MAINTAINERS entry. commit 36d0344c254a7b333272757f858c403ea3a2d29f upstream. Add the xHCI driver files to its MAINTAINERS entry so that I'm Cc'd on cleanup patches. Update the email address to one I actually use for sending patches and responding to Linux mailing list emails. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit b71a005bac02d0f68ba2d93f47cd58afcd563149 Author: Theodore Ts'o Date: Sun Nov 15 15:31:37 2009 -0500 jbd2: don't wipe the journal on a failed journal checksum commit e6a47428de84e19fda52f21ab73fde2906c40d09 upstream. If there is a failed journal checksum, don't reset the journal. This allows for userspace programs to decide how to recover from this situation. It may be that ignoring the journal checksum failure might be a better way of recovering the file system. Once we add per-block checksums, we can definitely do better. Until then, a system administrator can try backing up the file system image (or taking a snapshot) and and trying to determine experimentally whether ignoring the checksum failure or aborting the journal replay results in less data loss. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 943e167cb3e8fb191894bde8a4a75db78531a7c8 Author: Sebastian Andrzej Siewior Date: Sun Nov 29 19:46:02 2009 +0100 UBI: flush wl before clearing update marker commit 6afaf8a484cbbfd2ccf58a4e5396d1f280469789 upstream. ubiupdatevol -t does the following: - ubi_start_update() - set_update_marker() - for all LEBs ubi_eba_unmap_leb() - clear_update_marker() - ubi_wl_flush() ubi_wl_flush() physically erases all PEB, once it returns all PEBs are empty. clear_update_marker() has the update marker written after return. If there is a power cut between the last two functions then the UBI volume has no longer the "update" marker set and may have some valid LEBs while some of them may be gone. If that volume in question happens to be a UBIFS volume, then mount will fail with |UBIFS error (pid 1361): ubifs_read_node: bad node type (255 but expected 6) |UBIFS error (pid 1361): ubifs_read_node: bad node at LEB 0:0 |Not a node, first 24 bytes: |00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff if there is at least one valid LEB and the wear-leveling worker managed to clear LEB 0. The patch waits for the wl worker to finish prior clearing the "update" marker on flash. The two new LEB which are scheduled for erasing after clear_update_marker() should not matter because they are only visible to UBI. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 220d5b50cab3a384584f767075b02bdfc53c8c77 Author: Alexey Dobriyan Date: Mon Dec 14 17:57:34 2009 -0800 bsdacct: fix uid/gid misreporting commit 4b731d50ff3df6b9141a6c12b088e8eb0109e83c upstream. commit d8e180dcd5bbbab9cd3ff2e779efcf70692ef541 "bsdacct: switch credentials for writing to the accounting file" introduced credential switching during final acct data collecting. However, uid/gid pair continued to be collected from current which became credentials of who created acct file, not who exits. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14676 Signed-off-by: Alexey Dobriyan Reported-by: Juho K. Juopperi Acked-by: Serge Hallyn Acked-by: David Howells Reviewed-by: Michal Schmidt Cc: James Morris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 839646ece349e6ac42ecae95200c9e950c14e4de Author: Roel Kluin Date: Fri Nov 20 15:34:13 2009 -0300 V4L/DVB: Fix test in copy_reg_bits() commit c95a419a5604ec8a23cd73f61e9bb151e8cbe89b upstream. The reg_pair2[j].reg was tested twice. Signed-off-by: Roel Kluin Acked-by: Michael Krufky Signed-off-by: Andrew Morton Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ea76a1295e44ace82062690bca71436f03b26c39 Author: Hendrik Brueckner Date: Mon Dec 7 12:44:42 2009 +0100 s390: clear high-order bits of registers after sam64 commit cf87b7439ec81b9374e7772e44e9cb2eb9e57160 upstream. When the kernel is IPLed without the CLEAR option and switches to 64-bit, the high-order half of the registers might contain random values. This can cause addressing exceptions and the kernel enters an interrupt loop. Initialize the high-order half of the general purpose registers with zeros after switching to 64-bit mode. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit effa97cc19cf828bc21c950c1c19e2deef11e874 Author: Sergei Shtylyov Date: Fri Nov 27 22:29:02 2009 +0400 pata_hpt{37x|3x2n}: fix timing register masks (take 2) commit 5600c70e576199a7552e1c0fff43f3fe16f5566e upstream. These drivers inherited from the older 'hpt366' IDE driver the buggy timing register masks in their set_piomode() metods. As a result, too low command cycle active time is programmed for slow PIO modes. Quite fortunately, it's later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA mode #N also reprograms already set PIO data timings, usually to MWDMA mode # max(N, 2) timings... However, the drivers added some breakage of their own too: the bit that they set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of the command cycle setup time; also, setting it in DMA mode is wrong as this bit is only for PIO actually and clearing it for PIO modes is not needed as no mode in any timing table has it set... Fix all this, inverting the masks while at it, like in the 'hpt366' and 'pata_hpt366' drivers; bump the drivers' versions, accounting for recent patches that forgot to do it... Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit dff8a48a124bd07016f5900061bdf6f4cef6a953 Author: Dave Jones Date: Tue Nov 10 15:01:20 2009 -0500 x86: Fix typo in Intel CPU cache size descriptor commit e02e0e1a130b9ca37c5186d38ad4b3aaf58bb149 upstream. I double-checked the datasheet. One of the existing descriptors has a typo: it should be 2MB not 2038 KB. Signed-off-by: Dave Jones LKML-Reference: <20091110200120.GA27090@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 04071db2c1079698a87d371fd67aef4ad6cd6db1 Author: Dave Jones Date: Tue Nov 10 13:49:24 2009 -0500 x86: Add new Intel CPU cache size descriptors commit 85160b92fbd35321104819283c91bfed2b553e3c upstream. The latest rev of Intel doc AP-485 details new cache descriptors that we don't yet support. 12MB, 18MB and 24MB 24-way assoc L3 caches. Signed-off-by: Dave Jones LKML-Reference: <20091110184924.GA20337@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit cf8b14f356f1ab35c88209c7efb3050bbb473946 Author: Cliff Wickman Date: Fri Dec 11 11:36:18 2009 -0600 x86: Fix duplicated UV BAU interrupt vector commit 1d865fb728bd6bbcdfbd6ec1e2b8ade3b4805641 upstream. Interrupt vector 0xec has been doubly defined in irq_vectors.h It seems arbitrary whether LOCAL_PENDING_VECTOR or UV_BAU_MESSAGE is the higher number. As long as they are unique. If they are not unique we'll hit a BUG in alloc_system_vector(). Signed-off-by: Cliff Wickman LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3715cace63b4751445181cefcb2eba77b30d8525 Author: Cliff Wickman Date: Thu Nov 19 17:12:43 2009 -0600 x86: SGI UV: Fix BAU initialization commit e38e2af1c57c3eb5211331a5b4fcaae0c4a2a918 upstream. A memory mapped register that affects the SGI UV Broadcast Assist Unit's interrupt handling may sometimes be unintialized. Remove the condition on its initialization, as that condition can be randomly satisfied by a hardware reset. Signed-off-by: Cliff Wickman LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e8aab284380017e1aee419ab45e87d89eff8cf00 Author: Jan Beulich Date: Tue Dec 8 11:21:37 2009 +0900 x86/mce: Set up timer unconditionally commit bc09effabf0c5c6c7021e5ef9af15a23579b32a8 upstream. mce_timer must be passed to setup_timer() in all cases, no matter whether it is going to be actually used. Otherwise, when the CPU gets brought down, its call to del_timer_sync() will never return, as the timer won't have a base associated, and hence lock_timer_base() will loop infinitely. Signed-off-by: Jan Beulich Signed-off-by: Hidetoshi Seto LKML-Reference: <4B1DB831.2030801@jp.fujitsu.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 05217134d25f399adb7bb3db195e7dc64ad77289 Author: Hidetoshi Seto Date: Thu Dec 3 11:33:08 2009 +0900 x86, mce: don't restart timer if disabled commit fe5ed91ddce85a0ed0e4f92c10b099873ef62167 upstream. Even it is in error path unlikely taken, add_timer_on() at CPU_DOWN_FAILED* needs to be skipped if mce_timer is disabled. Signed-off-by: Hidetoshi Seto Cc: Andi Kleen Cc: Huang Ying Cc: Jan Beulich Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit ceb9c79365c6eb4971effbb28c118874ae83410e Author: Thomas Gleixner Date: Sat Nov 28 15:03:03 2009 +0100 x86: Use -maccumulate-outgoing-args for sane mcount prologues commit b8b7d791a8ff01d2380089279a69afa99115fb23 upstream. commit 746357d (x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage) uses -mtune=generic to work around the function prologue problem with mcount on -march=pentium-mmx and others. Jakub pointed out that we can use -maccumulate-outgoing-args instead which is selected by -mtune=generic and prevents the problem without losing the -march specific optimizations. Pointed-out-by: Jakub Jelinek Signed-off-by: Thomas Gleixner Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8de7f4a42cbdaa15a05b22fcfa01d38b6f8e0f5b Author: Thomas Gleixner Date: Fri Nov 20 12:01:43 2009 +0100 x86: Prevent GCC 4.4.x (pentium-mmx et al) function prologue wreckage commit 746357d6a526d6da9d89a2ec645b28406e959c2e upstream. When the kernel is compiled with -pg for tracing GCC 4.4.x inserts stack alignment of a function _before_ the mcount prologue if the -march=pentium-mmx is set and -mtune=generic is not set. This breaks the assumption of the function graph tracer which expects that the mcount prologue push %ebp mov %esp, %ebp is the first stack operation in a function because it needs to modify the function return address on the stack to trap into the tracer before returning to the real caller. The generated code is: push %edi lea 0x8(%esp),%edi and $0xfffffff0,%esp pushl -0x4(%edi) push %ebp mov %esp,%ebp so the tracer modifies the copy of the return address which is stored after the stack alignment and therefor does not trap the return which in turn breaks the call chain logic of the tracer and leads to a kernel panic. Aside of the fact that the generated code is horrible for no good reason other -march -mtune options generate the expected: push %ebp mov %esp,%ebp and $0xfffffff0,%esp which does the same and keeps everything intact. After some experimenting we found out that this problem is restricted to gcc4.4.x and to the following -march settings: i586, pentium, pentium-mmx, k6, k6-2, k6-3, winchip-c6, winchip2, c3, geode By adding -mtune=generic the code generator produces always the expected code. So forcing -mtune=generic when CONFIG_FUNCTION_GRAPH_TRACER=y is not pretty, but at the moment the only way to prevent that the kernel trips over gcc-shrooms induced code madness. Most distro kernels have CONFIG_X86_GENERIC=y anyway which forces -mtune=generic as well so it will not impact those. References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109 http://lkml.org/lkml/2009/11/19/17 Signed-off-by: Thomas Gleixner LKML-Reference: Cc: Linus Torvalds Cc: Andrew Morton Cc: Ingo Molnar Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Steven Rostedt Cc: Frederic Weisbecker , Cc: Jeff Law Cc: gcc@gcc.gnu.org Cc: David Daney Cc: Andrew Haley Cc: Richard Guenther Signed-off-by: Greg Kroah-Hartman commit a55770ccda90d9c1ed3b2408ea93f346278e6522 Author: Glauber Costa Date: Tue Oct 6 13:24:50 2009 -0400 KVM: x86: include pvclock MSRs in msrs_to_save commit e3267cbbbfbcbe9c18833e89b10beabb1117cb55 upstream. For a while now, we are issuing a rdmsr instruction to find out which msrs in our save list are really supported by the underlying machine. However, it fails to account for kvm-specific msrs, such as the pvclock ones. This patch moves then to the beginning of the list, and skip testing them. Signed-off-by: Glauber Costa Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 310c1a04807321c666445292db4b9147f1174c08 Author: Marcelo Tosatti Date: Sat Oct 17 22:47:23 2009 -0300 KVM: fix irq_source_id size verification commit cd5a2685de4a642fd0bd763e8c19711ef08dbe27 upstream. find_first_zero_bit works with bit numbers, not bytes. Fixes https://sourceforge.net/tracker/?func=detail&aid=2847560&group_id=180599&atid=893831 Reported-by: "Xu, Jiajun" Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit fff7d05d83d41107dd1c8740cfbfd50fe3ce87e8 Author: Carsten Otte Date: Thu Nov 19 14:21:16 2009 +0100 KVM: s390: Make psw available on all exits, not just a subset commit d7b0b5eb3000c6fb902f08c619fcd673a23d8fab upstream. This patch moves s390 processor status word into the base kvm_run struct and keeps it up-to date on all userspace exits. The userspace ABI is broken by this, however there are no applications in the wild using this. A capability check is provided so users can verify the updated API exists. Signed-off-by: Carsten Otte Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit f7b0fd208527e8f755e06411821efb5cc89c0868 Author: Carsten Otte Date: Mon Nov 30 17:14:41 2009 +0100 KVM: s390: Fix prefix register checking in arch/s390/kvm/sigp.c commit f50146bd7bdb75435638e60d4960edd9bcdf88b8 upstream. This patch corrects the checking of the new address for the prefix register. On s390, the prefix register is used to address the cpu's lowcore (address 0...8k). This check is supposed to verify that the memory is readable and present. copy_from_guest is a helper function, that can be used to read from guest memory. It applies prefixing, adds the start address of the guest memory in user, and then calls copy_from_user. Previous code was obviously broken for two reasons: - prefixing should not be applied here. The current prefix register is going to be updated soon, and the address we're looking for will be 0..8k after we've updated the register - we're adding the guest origin (gmsor) twice: once in subject code and once in copy_from_guest With kuli, we did not hit this problem because (a) we were lucky with previous prefix register content, and (b) our guest memory was mmaped very low into user address space. Signed-off-by: Carsten Otte Reported-by: Alexander Graf Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit b63569376aeca6300e10bf9e5ccfc49758407dbf Author: Avi Kivity Date: Tue Nov 24 15:20:15 2009 +0200 KVM: x86 emulator: limit instructions to 15 bytes commit eb3c79e64a70fb8f7473e30fa07e89c1ecc2c9bb upstream. While we are never normally passed an instruction that exceeds 15 bytes, smp games can cause us to attempt to interpret one, which will cause large latencies in non-preempt hosts. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 7cb056b8203edc77c0b69431cf1312805a008484 Author: Jaroslav Kysela Date: Wed Dec 9 10:44:47 2009 +0100 ALSA: hda - Terradici HDA controllers does not support 64-bit mode commit 396087eaead95fcb29eb36f1e59517aeb58c545e upstream. Confirmed from vendor and tests in RedHat bugzilla #536782 . Signed-off-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f6f725781c331351cdcaaec322706d342e285122 Author: Takashi Iwai Date: Fri Dec 11 12:51:05 2009 +0100 ALSA: hrtimer - Fix lock-up commit fcfdebe70759c74e2e701f69aaa7f0e5e32cf5a6 upstream. The timer stop callback can be called from snd_timer_interrupt(), which is called from the hrtimer callback. Since hrtimer_cancel() waits for the callback completion, this eventually results in a lock-up. This patch fixes the problem by just toggling a flag at stop callback and call hrtimer_cancel() later. Reported-and-tested-by: Wojtek Zabolotny Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 630d0a27ad4eabede5defec0595b8a703d5b6b71 Author: Feng Tang Date: Thu Sep 3 16:32:53 2009 +0800 hrtimer: Fix /proc/timer_list regression commit 8629ea2eaba8ca0de2e38ce1b4a825e16255976e upstream. commit 507e1231 (timer stats: Optimize by adding quick check to avoid function calls) introduced a regression in /proc/timer_list. /proc/timer_list shows now #0: , tick_sched_timer, S:01, <(null)>, /-1 instead of #0: , tick_sched_timer, S:01, hrtimer_start, swapper/0 Revert the hrtimer quick check for now. The optimization needs more thought, but this is neither 2.6.32-rc7 nor stable material. [ tglx: - Removed unrelated changes from the original patch - Prevent unneccesary call to timer_stats_update_stats - massaged the changelog ] Signed-off-by: Feng Tang LKML-Reference: Cc: Heiko Carstens Signed-off-by: Andrew Morton Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 Author: Luis R. Rodriguez Date: Wed Nov 25 17:23:26 2009 -0500 ath5k: enable EEPROM checksum check commit 512414b0bed0d376ac4d5ec1dd6f0b1a3551febc upstream. Without this we have no gaurantee of the integrity of the EEPROM and are likely to encounter a lot of bogus bug reports due to actual issues on the EEPROM. With the EEPROM checksum check in place we can easily rule those issues out. If you run patch during a revert *you* have a card with a busted EEPROM and only older kernel will support that concoction. This patch is a trade off between not accepitng bogus EEPROMs and avoiding bogus bug reports allowing developers to focus instead on real concrete issues. If stable keeps bogus bug reports because of a possibly busted EEPROM feel free to apply this there too. Tested on an AR5414 Cc: jirislaby@gmail.com Cc: akpm@linux-foundation.org Cc: rjw@sisk.pl Cc: me@bobcopeland.com Cc: david.quan@atheros.com Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f0da7d9ab2ab222669e51f0404dc9b4e2fef9944 Author: Bob Copeland Date: Mon Nov 16 08:30:29 2009 -0500 ath5k: allow setting txpower to 0 commit 2eb2fa67e5462a36e98172fb92c78bc405b3035f upstream. As a holdover from earlier code when we used to set the power limit to '0' after a reset to configure the default transmit power, ath5k interprets txpower=0 as 12.5 dBm. Fix that by just passing 0 through. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14567 Reported-by: Daniel Folkers Tested-by: Daniel Folkers Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ee17dd1efa301f6d113f461db7e2b9c06655f3fb Author: Michael Buesch Date: Mon Nov 23 20:58:06 2009 +0100 ssb: Fix range check in sprom write commit e33761e6f23881de9f3ee77cc2204ab2e26f3d9a upstream. The range check in the sprom image parser hex2sprom() is broken. One sprom word is 4 hex characters. This fixes the check and also adds much better sanity checks to the code. We better make sure the image is OK by doing some sanity checks to avoid bricking the device by accident. Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8224532f94891bab12398b06c6359f0ce148a285 Author: Mikael Pettersson Date: Thu Dec 3 15:52:44 2009 +0100 x86, apic: Enable lapic nmi watchdog on AMD Family 11h commit 7d1849aff6687a135a8da3a75e32a00e3137a5e2 upstream. The x86 lapic nmi watchdog does not recognize AMD Family 11h, resulting in: NMI watchdog: CPU not supported As far as I can see from available documentation (the BKDM), family 11h looks identical to family 10h as far as the PMU is concerned. Extending the check to accept family 11h results in: Testing NMI watchdog ... OK. I've been running with this change on a Turion X2 Ultra ZM-82 laptop for a couple of weeks now without problems. Signed-off-by: Mikael Pettersson Cc: Andreas Herrmann Cc: Joerg Roedel LKML-Reference: <19223.53436.931768.278021@pilspetsen.it.uu.se> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 78a794f462df2a701b754fd17415a88b8bf1bc61 Author: Leann Ogasawara Date: Fri Dec 4 15:42:22 2009 -0800 x86: ASUS P4S800 reboot=bios quirk commit 4832ddda2ec4df96ea1eed334ae2dbd65fc1f541 upstream. Bug reporter noted their system with an ASUS P4S800 motherboard would hang when rebooting unless reboot=b was specified. Their dmidecode didn't contain descriptive System Information for Manufacturer or Product Name, so I used their Base Board Information to create a reboot quirk patch. The bug reporter confirmed this patch resolves the reboot hang. Handle 0x0001, DMI type 1, 25 bytes System Information Manufacturer: System Manufacturer Product Name: System Name Version: System Version Serial Number: SYS-1234567890 UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F Wake-up Type: Power Switch Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P4S800 Version: REV 1.xx Serial Number: xxxxxxxxxxx BugLink: http://bugs.launchpad.net/bugs/366682 ASUS P4S800 will hang when rebooting unless reboot=b is specified. Add a quirk to reboot through the bios. Signed-off-by: Leann Ogasawara LKML-Reference: <1259972107.4629.275.camel@emiko> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 900f42a14f80f9bbb8e8695bb2fe38c310af656e Author: Joe Perches Date: Mon Nov 9 17:58:50 2009 -0800 x86: GART: pci-gart_64.c: Use correct length in strncmp commit 41855b77547fa18d90ed6a5d322983d3fdab1959 upstream. Signed-off-by: Joe Perches LKML-Reference: <1257818330.12852.72.camel@Joe-Laptop.home> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 704c528bee45fc37546542bf578181cec0845a67 Author: Tejun Heo Date: Mon Oct 26 15:41:46 2009 +0100 x86: Fix iommu=nodac parameter handling commit 2ae8bb75db1f3de422eb5898f2a063c46c36dba8 upstream. iommu=nodac should forbid dac instead of enabling it. Fix it. Signed-off-by: Tejun Heo Acked-by: FUJITA Tomonori Cc: Matteo Frigo LKML-Reference: <4AE5B52A.4050408@kernel.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7da88e8e91d39462ca08393de81b78b9507f8281 Author: Darrick J. Wong Date: Wed Dec 2 15:05:56 2009 -0800 x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree commit 4528752f49c1f4025473d12bc5fa9181085c3f22 upstream. On a multi-node x3950M2 system, there's a slight oddity in the PCI device tree for all secondary nodes: 30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) ...as compared to the primary node: 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) 03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) In both nodes, the LSI RAID controller hangs off a CalIOC2 device, but on the secondary nodes, the BIOS hides the VGA device and substitutes the device tree ending with the disk controller. It would seem that Calgary devices don't necessarily appear at the top of the PCI tree, which means that the current code to find the Calgary IOMMU that goes with a particular device is buggy. Rather than walk all the way to the top of the PCI device tree and try to match bus number with Calgary descriptor, the code needs to examine each parent of the particular device; if it encounters a Calgary with a matching bus number, simply use that. Otherwise, we BUG() when the bus number of the Calgary doesn't match the bus number of whatever's at the top of the device tree. Extra note: This patch appears to work correctly for the x3950 that came before the x3950 M2. Signed-off-by: Darrick J. Wong Acked-by: Muli Ben-Yehuda Cc: FUJITA Tomonori Cc: Joerg Roedel Cc: Yinghai Lu Cc: Jon D. Mason Cc: Corinna Schultz LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e81ccb78036da2a31adc51ed676dbf2f158374f7 Author: Joerg Roedel Date: Mon Nov 23 12:45:25 2009 +0100 x86/amd-iommu: un__init iommu_setup_msi commit 9f800de38b05d84809e89f16671d636a140eede7 upstream. This function may be called on the resume path and can not be dropped after booting. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 430b6ab743b6448873d4d9382af6c3f860dfdbb4 Author: Joerg Roedel Date: Mon Nov 23 12:50:00 2009 +0100 x86/amd-iommu: attach devices to pre-allocated domains early commit be831297716036de5b24308447ecb69f1706a846 upstream. For some devices the ACPI table may define unity map requirements which must me met when the IOMMU is enabled. So we need to attach devices to their domains as early as possible so that these mappings are in place when needed. This patch assigns the domains right after they are allocated. Otherwise this can result in I/O page faults before a driver binds to a device and BIOS is still using it. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 35c1ee3e78766d5666f418af638def9c67e63ecb Author: Mike Galbraith Date: Tue Nov 10 03:50:02 2009 +0100 sched: Fix and clean up rate-limit newidle code commit eae0c9dfb534cb3449888b9601228efa6480fdb5 upstream. Commit 1b9508f, "Rate-limit newidle" has been confirmed to fix the netperf UDP loopback regression reported by Alex Shi. This is a cleanup and a fix: - moved to a more out of the way spot - fix to ensure that balancing doesn't try to balance runqueues which haven't gone online yet, which can mess up CPU enumeration during boot. Reported-by: Alex Shi Reported-by: Zhang, Yanmin Signed-off-by: Mike Galbraith Acked-by: Peter Zijlstra LKML-Reference: <1257821402.5648.17.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 37ed2d7007a65874850f3e357c095806c3756330 Author: Mike Galbraith Date: Wed Nov 4 17:53:50 2009 +0100 sched: Rate-limit newidle commit 1b9508f6831e10d53256825de8904caa22d1ca2c upstream. Rate limit newidle to migration_cost. It's a win for all stages of sysbench oltp tests. Signed-off-by: Mike Galbraith Cc: Peter Zijlstra LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ece125459cc4ea8ec5344a2d12cee4b42602b822 Author: Mike Galbraith Date: Thu Nov 5 10:57:46 2009 +0100 sched: Fix affinity logic in select_task_rq_fair() commit fd210738f6601d0fb462df9a2fe5a41896ff6a8f upstream. Ingo Molnar reported: [ 26.804000] BUG: using smp_processor_id() in preemptible [00000000] code: events/1/10 [ 26.808000] caller is vmstat_update+0x26/0x70 [ 26.812000] Pid: 10, comm: events/1 Not tainted 2.6.32-rc5 #6887 [ 26.816000] Call Trace: [ 26.820000] [] ? printk+0x28/0x3c [ 26.824000] [] debug_smp_processor_id+0xf0/0x110 [ 26.824000] mount used greatest stack depth: 1464 bytes left [ 26.828000] [] vmstat_update+0x26/0x70 [ 26.832000] [] worker_thread+0x188/0x310 [ 26.836000] [] ? worker_thread+0x127/0x310 [ 26.840000] [] ? autoremove_wake_function+0x0/0x60 [ 26.844000] [] ? worker_thread+0x0/0x310 [ 26.848000] [] kthread+0x7c/0x90 [ 26.852000] [] ? kthread+0x0/0x90 [ 26.856000] [] kernel_thread_helper+0x7/0x10 [ 26.860000] BUG: using smp_processor_id() in preemptible [00000000] code: events/1/10 [ 26.864000] caller is vmstat_update+0x3c/0x70 Because this commit: a1f84a3: sched: Check for an idle shared cache in select_task_rq_fair() broke ->cpus_allowed. Signed-off-by: Mike Galbraith Cc: Peter Zijlstra Cc: arjan@infradead.org LKML-Reference: <1257415066.12867.1.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c2f1953231c6e99777633761c3bc0d2ca7ead20a Author: Mike Galbraith Date: Tue Oct 27 15:35:38 2009 +0100 sched: Check for an idle shared cache in select_task_rq_fair() commit a1f84a3ab8e002159498814eaa7e48c33752b04b upstream. When waking affine, check for an idle shared cache, and if found, wake to that CPU/sibling instead of the waker's CPU. This improves pgsql+oltp ramp up by roughly 8%. Possibly more for other loads, depending on overlap. The trade-off is a roughly 1% peak downturn if tasks are truly synchronous. Signed-off-by: Mike Galbraith Cc: Arjan van de Ven Cc: Peter Zijlstra LKML-Reference: <1256654138.17752.7.camel@marge.simson.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7f112f35f0da073a10d4d3bfdfcef2955555e4f7 Author: Rafael J. Wysocki Date: Thu Dec 3 20:21:21 2009 +0100 PM / Runtime: Fix lockdep warning in __pm_runtime_set_status() commit bab636b921017f0db6e0c2979438f50b898a9808 upstream. Lockdep complains about taking the parent lock in __pm_runtime_set_status(), so mark it as nested. Signed-off-by: Rafael J. Wysocki Reported-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 9f3bb2b1e8f891b008ab3d74d789444cab5ef695 Author: Kristian Høgsberg Date: Tue Dec 1 15:05:01 2009 -0500 perf: Don't free perf_mmap_data until work has been done commit ec70ccd806111ba3caf596def91a8580138b12db upstream. In the CONFIG_PERF_USE_VMALLOC case, perf_mmap_data_free() only schedules the cleanup of the perf_mmap_data struct. In that case we have to wait until the work has been done before we free data. Signed-off-by: Kristian Høgsberg Cc: David S. Miller Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Frederic Weisbecker LKML-Reference: <1259697901-1747-1-git-send-email-krh@bitplanet.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b7b4aef82aeef0d9408951c8d1e7a2a6dd359921 Author: Xiao Guangrong Date: Tue Dec 1 17:30:08 2009 +0800 perf_event: Initialize data.period in perf_swevent_hrtimer() commit 59d069eb5ae9b033ed1c124c92e1532c4a958991 upstream. In current code in perf_swevent_hrtimer(), data.period is not initialized, The result is obvious wrong: # ./perf record -f -e cpu-clock make # ./perf report # Samples: 1740 # # Overhead Command ...... # ........ ........ .......................................... # 1025422183050275328.00% sh libc-2.9.90.so ... 1025422183050275328.00% perl libperl.so ... 1025422168240043264.00% perl [kernel] ... 1025422030011210752.00% perl [kernel] ... Signed-off-by: Xiao Guangrong Acked-by: Peter Zijlstra Cc: Frederic Weisbecker LKML-Reference: <4B14E220.2050107@cn.fujitsu.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c64d2a3d2c5f192d859374e943968439afb0f995 Author: Arjan van de Ven Date: Fri Nov 13 21:47:33 2009 -0800 perf_event: Fix invalid type in ioctl definition commit 4c49b12853fbb5eff4849b7b6a1e895776f027a1 upstream. u64 is invalid in userspace headers, including ioctl definitions; use __u64 instead Signed-off-by: Arjan van de Ven LKML-Reference: <20091113214733.7cd76be9@infradead.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b87444a84534cba3ba85536cabfcaf364c0fa940 Author: Paul E. McKenney Date: Tue Nov 10 13:37:19 2009 -0800 rcu: Remove inline from forward-referenced functions commit dbe01350fa8ce0c11948ab7d6be71a4d901be151 upstream. Some variants of gcc are reputed to dislike forward references to functions declared "inline". Remove the "inline" keyword from such functions. Signed-off-by: Paul E. McKenney Cc: laijs@cn.fujitsu.com Cc: dipankar@in.ibm.com Cc: mathieu.desnoyers@polymtl.ca Cc: josh@joshtriplett.org Cc: dvhltc@us.ibm.com Cc: niv@us.ibm.com Cc: peterz@infradead.org Cc: rostedt@goodmis.org Cc: Valdis.Kletnieks@vt.edu Cc: dhowells@redhat.com Cc: Benjamin Gilbert LKML-Reference: <12578890422402-git-send-email-> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c541f7c75c5d41c9a3f2c7599ee425547cc49a42 Author: Paul E. McKenney Date: Mon Nov 2 13:52:29 2009 -0800 rcu: Fix note_new_gpnum() uses of ->gpnum commit 9160306e6f5b68bb64630c9031c517ca1cf463db upstream. Impose a clear locking design on the note_new_gpnum() function's use of the ->gpnum counter. This is done by updating rdp->gpnum only from the corresponding leaf rcu_node structure's rnp->gpnum field, and even then only under the protection of that same rcu_node structure's ->lock field. Performance and scalability are maintained using a form of double-checked locking, and excessive spinning is avoided by use of the spin_trylock() function. The use of spin_trylock() is safe due to the fact that CPUs who fail to acquire this lock will try again later. The hierarchical nature of the rcu_node data structure limits contention (which could be limited further if need be using the RCU_FANOUT kernel parameter). Without this patch, obscure but quite possible races could result in a quiescent state that occurred during one grace period to be accounted to the following grace period, causing this following grace period to end prematurely. Not good! Signed-off-by: Paul E. McKenney Cc: laijs@cn.fujitsu.com Cc: dipankar@in.ibm.com Cc: mathieu.desnoyers@polymtl.ca Cc: josh@joshtriplett.org Cc: dvhltc@us.ibm.com Cc: niv@us.ibm.com Cc: peterz@infradead.org Cc: rostedt@goodmis.org Cc: Valdis.Kletnieks@vt.edu Cc: dhowells@redhat.com LKML-Reference: <12571987492350-git-send-email-> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1a0d7df3352d775ae3e034b1f2658ea493055a30 Author: Paul E. McKenney Date: Mon Nov 2 13:52:28 2009 -0800 rcu: Fix synchronization for rcu_process_gp_end() uses of ->completed counter commit d09b62dfa336447c52a5ec9bb88adbc479b0f3b8 upstream. Impose a clear locking design on the rcu_process_gp_end() function's use of the ->completed counter. This is done by creating a ->completed field in the rcu_node structure, which can safely be accessed under the protection of that structure's lock. Performance and scalability are maintained by using a form of double-checked locking, so that rcu_process_gp_end() only acquires the leaf rcu_node structure's ->lock if a grace period has recently ended. This fix reduces rcutorture failure rate by at least two orders of magnitude under heavy stress with force_quiescent_state() being invoked artificially often. Without this fix, unsynchronized access to the ->completed field can cause rcu_process_gp_end() to advance callbacks whose grace period has not yet expired. (Bad idea!) Signed-off-by: Paul E. McKenney Cc: laijs@cn.fujitsu.com Cc: dipankar@in.ibm.com Cc: mathieu.desnoyers@polymtl.ca Cc: josh@joshtriplett.org Cc: dvhltc@us.ibm.com Cc: niv@us.ibm.com Cc: peterz@infradead.org Cc: rostedt@goodmis.org Cc: Valdis.Kletnieks@vt.edu Cc: dhowells@redhat.com LKML-Reference: <12571987494069-git-send-email-> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1aab3863fee66343b420cb1e5d268c3ee8da27a6 Author: Paul E. McKenney Date: Mon Nov 2 13:52:27 2009 -0800 rcu: Prepare for synchronization fixes: clean up for non-NO_HZ handling of ->completed counter commit 281d150c5f8892f158747594ab49ce2823fd8b8c upstream. Impose a clear locking design on non-NO_HZ handling of the ->completed counter. This increases the distance between the RCU and the CPU-hotplug mechanisms. Signed-off-by: Paul E. McKenney Cc: laijs@cn.fujitsu.com Cc: dipankar@in.ibm.com Cc: mathieu.desnoyers@polymtl.ca Cc: josh@joshtriplett.org Cc: dvhltc@us.ibm.com Cc: niv@us.ibm.com Cc: peterz@infradead.org Cc: rostedt@goodmis.org Cc: Valdis.Kletnieks@vt.edu Cc: dhowells@redhat.com LKML-Reference: <12571987491353-git-send-email-> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e39b7b492b646e803941117e5d879e49f40bb92f Author: Jay Fenlason Date: Fri Dec 11 14:23:58 2009 -0500 firewire: ohci: handle receive packets with a data length of zero commit 8c0c0cc2d9f4c523fde04bdfe41e4380dec8ee54 upstream. Queueing to receive an ISO packet with a payload length of zero silently does nothing in dualbuffer mode, and crashes the kernel in packet-per-buffer mode. Return an error in dualbuffer mode, because the DMA controller won't let us do what we want, and work correctly in packet-per-buffer mode. Signed-off-by: Jay Fenlason Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit be58b8712a2309b71d1c99ae648bca2d34c55781 Author: zhao.ming9@zte.com.cn Date: Mon Dec 7 11:36:34 2009 +0800 USB: option: add pid for ZTE commit 8d87cacda7c8db5c131bfcaaa1d90bfe918c2ebc upstream. This patch adds ZTE modem devices. Signed-off-by: Ming Zhao Signed-off-by: Greg Kroah-Hartman commit 5a2ec9e5ec191d610d56433f3801b7fb9e250872 Author: Alan Stern Date: Mon Dec 7 16:47:43 2009 -0500 USB: usb-storage: fix bug in fill_inquiry commit f3f6faa9edf67c1018270793e0547b0f81abb47e upstream. This patch (as1312) fixes a minor bug in usb-storage. The fill_inquiry() routine neglects to pre-load the inquiry data buffer with spaces. As a result, if the vendor name is shorter than 8 characters or the product name is shorter than 16, the remainder will be filled with garbage. The patch also removes some unnecessary calls to strlen(). Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman