commit 69ad303ab8321656d6144d13b2444a5595bb6581 Author: Greg Kroah-Hartman Date: Thu Feb 17 15:14:38 2011 -0800 Linux 2.6.36.4 commit 062d29c90bda892a67eecb5e972715e1bd5df9cd Author: Sarah Sharp Date: Tue Dec 28 13:08:42 2010 -0800 xhci: Use GFP_NOIO during device reset. commit a6d940dd759bf240d28624198660ed34582a327b upstream. When xhci_discover_or_reset_device() is called after a host controller power loss, the virtual device may need to be reallocated. Make sure xhci_alloc_dev() uses GFP_NOIO. This avoid causing a deadlock by allowing the kernel to flush pending I/O while reallocating memory for a virtual device for a USB mass storage device that's holding the backing store for dirty memory buffers. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit cc402387cc7fdb826b193994051dad64cdf6377b Author: Sarah Sharp Date: Thu Dec 23 11:12:42 2010 -0800 usb: Realloc xHCI structures after a hub is verified. commit 653a39d1f61bdc9f277766736d21d2e9be0391cb upstream. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 91e0d66a31148ff5108a1d877ddf54319903148b Author: Zhang Rui Date: Fri Dec 17 13:17:04 2010 -0800 xhci: Do not run xhci_cleanup_msix with irq disabled commit 40a9fb17f32dbe54de3d636142a59288544deed7 upstream. when unloading xhci_hcd, I got: [ 134.856813] xhci_hcd 0000:02:00.0: remove, state 4 [ 134.858140] usb usb3: USB disconnect, address 1 [ 134.874956] xhci_hcd 0000:02:00.0: Host controller not halted, aborting reset. [ 134.876351] BUG: sleeping function called from invalid context at kernel/mutex.c:85 [ 134.877657] in_atomic(): 0, irqs_disabled(): 1, pid: 1451, name: modprobe [ 134.878975] Pid: 1451, comm: modprobe Not tainted 2.6.37-rc5+ #162 [ 134.880298] Call Trace: [ 134.881602] [] __might_sleep+0xeb/0xf0 [ 134.882921] [] mutex_lock+0x24/0x50 [ 134.884229] [] free_desc+0x2e/0x5f [ 134.885538] [] irq_free_descs+0x3b/0x71 [ 134.886853] [] free_irq_at+0x31/0x36 [ 134.888167] [] destroy_irq+0x69/0x71 [ 134.889486] [] native_teardown_msi_irq+0xe/0x10 [ 134.890820] [] default_teardown_msi_irqs+0x57/0x80 [ 134.892158] [] free_msi_irqs+0x8b/0xe9 [ 134.893504] [] pci_disable_msix+0x35/0x39 [ 134.894844] [] xhci_cleanup_msix+0x31/0x51 [xhci_hcd] [ 134.896186] [] xhci_stop+0x3a/0x80 [xhci_hcd] [ 134.897521] [] usb_remove_hcd+0xfd/0x14a [ 134.898859] [] usb_hcd_pci_remove+0x5c/0xc6 [ 134.900193] [] pci_device_remove+0x3f/0x91 [ 134.901535] [] __device_release_driver+0x83/0xd9 [ 134.902899] [] driver_detach+0x86/0xad [ 134.904222] [] bus_remove_driver+0xb2/0xd8 [ 134.905540] [] driver_unregister+0x6c/0x74 [ 134.906839] [] pci_unregister_driver+0x44/0x89 [ 134.908121] [] xhci_unregister_pci+0x15/0x17 [xhci_hcd] [ 134.909396] [] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd] [ 134.910652] [] sys_delete_module+0x1ca/0x23b [ 134.911882] [] ? path_put+0x22/0x26 [ 134.913104] [] ? audit_syscall_entry+0x2c/0x148 [ 134.914333] [] system_call_fastpath+0x16/0x1b [ 134.915658] xhci_hcd 0000:02:00.0: USB bus 3 deregistered [ 134.916465] xhci_hcd 0000:02:00.0: PCI INT A disabled and the same issue when xhci_suspend is invoked. (Note from Sarah: That's fixed by Andiry's patch before this, by synchronizing the irqs rather than freeing them on suspend.) Do not run xhci_cleanup_msix with irq disabled. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Zhang Rui Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit a5caac7e5485057711085b764fb3ad95e071e6e5 Author: Chris Wilson Date: Tue Feb 1 19:43:02 2011 +0000 drm/i915: Only bind to function 0 of the PCI device commit 5fe49d86f9d01044abf687a8cd21edef636d58aa upstream. Early chipsets (gen2/3) used function 1 as a placeholder for multi-head. We used to ignore these since they were not assigned to PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu systems. This fails hard on gen2/3. Reported-by: Ferenc Wágner Tested-by: Ferenc Wágner Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012 Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 9487d9dcae378886b3d06452b630e211982a079a Author: Stephen Kitt Date: Mon Jan 31 14:25:43 2011 -0800 agp: ensure GART has an address before enabling it commit a70b95c017e8b518e1e069853355e4e497453dbb upstream. Some BIOSs (eg. the AMI BIOS on the Asus P4P800 motherboard) don't initialise the GART address, and pcibios_assign_resources() can ignore it because it can be marked as a host bridge (see https://bugzilla.kernel.org/show_bug.cgi?id=24392#c5 for details). This was handled correctly up to 2.6.35, but the pci_enable_device() cleanup in 2.6.36 96576a9e1a0cdb8 ("agp: intel-agp: do not use PCI resources before pci_enable_device()") means that the kernel tries to enable the GART before assigning it an address; in such cases the GART overlaps with other device assignments and ends up being disabled. This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=24392 Note that I imagine efficeon-agp.c probably has the same problem, but I can't test that and I'd like to make sure this patch is suitable for -stable (since 2.6.36 and 2.6.37 are affected). Signed-off-by: Stephen Kitt Cc: Bjorn Helgaas Cc: Maciej Rutecki Cc: "Rafael J. Wysocki" Cc: Kulikov Vasiliy Cc: Florian Mickler Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6d621e78c9e6efb6f4f2666434aa986bf6441195 Author: Suresh Siddha Date: Thu Feb 3 12:20:04 2011 -0800 x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm commit 831d52bc153971b70e64eccfbed2b232394f22f8 upstream. Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while the cr3 is still pointing to the prev mm. And this window can lead to the possibility of bogus TLB fills resulting in strange failures. One such problematic scenario is mentioned below. T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI etc between the point of clearing the cpu from the mm_cpumask(mm1) and before reloading the cr3 with the new mm2. T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with flushing the TLB for mm1. It doesn't send the flush TLB to CPU-1 as it doesn't see that cpu listed in the mm_cpumask(mm1). T3. After the TLB flush is complete, CPU-2 goes ahead and frees the page-table pages associated with the removed vma mapping. T4. CPU-2 now allocates those freed page-table pages for something else. T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1 can potentially speculate and walk through the page-table caches and can insert new TLB entries. As the page-table pages are already freed and being used on CPU-2, this page walk can potentially insert a bogus global TLB entry depending on the (random) contents of the page that is being used on CPU-2. T6. This bogus TLB entry being global will be active across future CR3 changes and can result in weird memory corruption etc. To avoid this issue, for the prev mm that is handing over the cpu to another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is changed. Marking it for -stable, though we haven't seen any reported failure that can be attributed to this. Signed-off-by: Suresh Siddha Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02a9f4dfb9318e84e6c46cd08adb286cfeaf87eb Author: Chris Wilson Date: Thu Jan 20 13:09:12 2011 +0000 drm/i915: Recognise non-VGA display devices commit 934f992c763ae1e5eefcce8af769c16444085df7 upstream. Starting with SandyBridge (though possible with earlier hacked BIOSes), the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior, it would simply disable the integrated GPU. So we adjust our PCI class mask to match any DISPLAY_CLASS device. In such a configuration, the IGFX is not a primary VGA controller and so should not take part in VGA arbitration, and the error return from vga_client_register() is expected. Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 5cc301295c277a59cb8ae9c529b6b1ef130fef0c Author: Chris Wilson Date: Thu Jan 20 10:03:24 2011 +0000 drm/i915: Add dependency on CONFIG_TMPFS commit f7ab9b407b3bc83161c2aa74c992ba4782e87c9c upstream. Without tmpfs, shmem_readpage() is not compiled in causing an OOPS as soon as we try to allocate some swappable pages for GEM. Jan 19 22:52:26 harlie kernel: Modules linked in: i915(+) drm_kms_helper cfbcopyarea video backlight cfbimgblt cfbfillrect Jan 19 22:52:26 harlie kernel: Jan 19 22:52:26 harlie kernel: Pid: 1125, comm: modprobe Not tainted 2.6.37Harlie #10 To be filled by O.E.M./To be filled by O.E.M. Jan 19 22:52:26 harlie kernel: EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 3 Jan 19 22:52:26 harlie kernel: EIP is at 0x0 Jan 19 22:52:26 harlie kernel: EAX: 00000000 EBX: f7b7d000 ECX: f3383100 EDX: f7b7d000 Jan 19 22:52:26 harlie kernel: ESI: f1456118 EDI: 00000000 EBP: f2303c98 ESP: f2303c7c Jan 19 22:52:26 harlie kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jan 19 22:52:26 harlie kernel: Process modprobe (pid: 1125, ti=f2302000 task=f259cd80 task.ti=f2302000) Jan 19 22:52:26 harlie kernel: Stack: Jan 19 22:52:26 harlie udevd-work[1072]: '/sbin/modprobe -b pci:v00008086d00000046sv00000000sd00000000bc03sc00i00' unexpected exit with status 0x0009 Jan 19 22:52:26 harlie kernel: c1074061 000000d0 f2f42b80 00000000 000a13d2 f2d5dcc0 00000001 f2303cac Jan 19 22:52:26 harlie kernel: c107416f 00000000 000a13d2 00000000 f2303cd4 f8d620ed f2cee620 00001000 Jan 19 22:52:26 harlie kernel: 00000000 000a13d2 f1456118 f2d5dcc0 f1a40000 00001000 f2303d04 f8d637ab Jan 19 22:52:26 harlie kernel: Call Trace: Jan 19 22:52:26 harlie kernel: [] ? do_read_cache_page+0x71/0x160 Jan 19 22:52:26 harlie kernel: [] ? read_cache_page_gfp+0x1f/0x30 Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_get_pages+0xad/0x1d0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_bind_to_gtt+0xeb/0x2d0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_pin+0x151/0x190 [i915] Jan 19 22:52:26 harlie kernel: [] ? drm_gem_object_init+0x3d/0x60 Jan 19 22:52:26 harlie kernel: [] ? i915_gem_init_ringbuffer+0x105/0x1e0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_driver_load+0x667/0x1160 [i915] Reported-by: John J. Stimson-III Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 660e15b4beb5de08c0cbde27bdea9800010b5d57 Author: Knut Petersen Date: Fri Jan 14 15:38:10 2011 +0000 drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS commit 22ab70d3262ddb6e69b3c246a34e2967ba5eb1e8 upstream. Signed-off-by: Knut Petersen Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 332db0727426a93e401c49fb04426d04c494c102 Author: Yuanhan Liu Date: Thu Jan 6 18:26:08 2011 +0800 drm/i915: fix calculation of eDP signal levels on Sandybridge commit 3c5a62b5226ca5db993660281e9c2a7275d9fb02 upstream. Some voltage swing/pre-emphasis level use the same value on eDP Sandybridge, like 400mv_0db and 600mv_0db are with the same value of (0x0 << 22). So, fix them, and point out the value if it isn't a supported voltage swing/pre-emphasis level. Signed-off-by: Yuanhan Liu Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 22747485265db8f9e104d2c21e5b98dd16d21993 Author: Chris Wilson Date: Sat Jan 8 15:10:41 2011 +0000 drm: Restore the old_fb upon modeset failure commit 0ba41e449fd0f45f5b29c1009020ab1b298bedda upstream. ... or else we may end up disabling the wrong framebuffer, leading to an OOPS, e.g: [ 6033.229012] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3271! [ 6033.229012] invalid opcode: 0000 [#1] SMP [ 6033.229012] last sysfs file: /sys/devices/virtual/backlight/acpi_video0/uevent [ 6033.229012] Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq mperf snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer thinkpad_acpi ppdev snd r852 sm_common iTCO_wdt uvcvideo i2c_i801 iTCO_vendor_support microcode wmi nand videodev nand_ids nand_ecc snd_page_alloc parport_pc parport mtd soundcore joydev v4l1_compat pcspkr uinput ipv6 sdhci_pci sdhci mmc_core yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 6033.229012] [ 6033.229012] Pid: 4834, comm: Xorg Not tainted 2.6.37-rc8+ #25 7661BL5/7661BL5 [ 6033.229012] EIP: 0060:[] EFLAGS: 00013246 CPU: 0 [ 6033.229012] EIP is at i915_gem_object_unpin+0x23/0x76 [i915] [ 6033.229012] EAX: f68a4000 EBX: f6831f00 ECX: 000600fa EDX: f68a8000 [ 6033.229012] ESI: f68a4014 EDI: f68a42b8 EBP: f2169c44 ESP: f2169c3c [ 6033.229012] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 6033.229012] Process Xorg (pid: 4834, ti=f2168000 task=f21c8000 task.ti=f2168000) [ 6033.229012] Stack: [ 6033.229012] f3a84800 f68a4014 f2169c54 f87045d8 f3a84800 f872d9a8 f2169c68 f7fd8091 [ 6033.229012] f3b952a4 00000000 f68a414c f2169cf0 f7fd9377 00000000 00000000 f7fd98b0 [ 6033.229012] f7fd9f4e 0000000f f7f328a0 00000000 00000000 00000000 f2169ca4 f68a414c [ 6033.229012] Call Trace: [ 6033.229012] [] ? intel_crtc_disable+0x36/0x41 [i915] [ 6033.229012] [] ? drm_helper_disable_unused_functions+0xcd/0xf9 [drm_kms_helper] [ 6033.229012] [] ? drm_crtc_helper_set_config+0x62a/0x7f7 [drm_kms_helper] [ 6033.229012] [] ? __slab_free+0x1b/0xa4 [ 6033.229012] [] ? drm_fb_helper_initial_config+0x466/0x497 [drm_kms_helper] [ 6033.229012] [] ? drm_fb_helper_restore+0x10/0x2a [drm_kms_helper] [ 6033.229012] [] ? i915_driver_lastclose+0x2a/0x57 [i915] [ 6033.229012] [] ? drm_lastclose+0x45/0x23e [drm] [ 6033.229012] [] ? drm_release+0x462/0x4d7 [drm] Signed-off-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 26c394589e578ec0056ef484ef1ace03a18089e5 Author: Alex Deucher Date: Wed Feb 2 19:46:06 2011 -0500 drm/radeon/kms: fix s/r issues with bios scratch regs commit 87364760de5d631390c478fcbac8db1b926e0adf upstream. The accelerate mode bit gets checked by certain atom command tables to set up some register state. It needs to be clear when setting modes and set when not. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26942 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 235eb7c354d3025e56d64e4869b3347ceb74284a Author: Alex Deucher Date: Tue Feb 1 19:06:46 2011 -0500 drm/radeon: remove 0x4243 pci id commit 63a507800c8aca5a1891d598ae13f829346e8e39 upstream. 0x4243 is a PCI bridge, not a GPU. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=33815 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 3e8db9f2984f4f75091d410ad37043266018c437 Author: Alex Deucher Date: Mon Jan 31 16:48:51 2011 -0500 drm/radeon/kms: add pll debugging output commit 51d4bf840a27fe02c883ddc6d9708af056773769 upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 55b95132272a078ce94d298b6a31a5e9ff924df2 Author: Jerome Glisse Date: Wed Jan 26 17:51:03 2011 -0500 radeon/kms: fix dp displayport mode validation commit 6bba2e116808ca12e30c8d88dfedabf8b8d67390 upstream. Check if there is a big enough dp clock & enough dp lane to drive the video mode provided. Signed-off-by: Jerome Glisse Reviewed-By: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0afec771614078f663e7847ab442723787c7abb1 Author: Alex Deucher Date: Tue Jan 18 18:26:11 2011 +0000 drm/radeon/kms: make the mac rv630 quirk generic commit be23da8ad219650517cbbb7acbeaeb235667113a upstream. Seems some other boards do this as well. Reported-by: Andrea Merello Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 76ca51b75747d69f4ff7d12f004cde5166d04fb5 Author: Alex Deucher Date: Tue Jan 4 17:42:20 2011 -0500 drm/radeon/kms: adjust quirk for acer laptop commit 2f299d5de02da3ffb1f9e1a05c91dcd1173ebd3c upstream. Acer laptop (TravelMate 5730G) has an HDMI connector on the laptop and a DVI connector on the docking station and both share the same encoder, hpd pin, and ddc line. The bios connector table reflects this and is technically correct, however, we drop the DVI connector here since xrandr has no concept of encoders (only crtcs and connectors) and will try and drive both connectors with different crtcs which isn't possible on the hardware side and leaves no crtcs for LVDS or VGA. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=32732 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 887c8377c0b96e5815b9c68ad969c6efb1b37e0d Author: Alex Deucher Date: Tue Jan 4 00:43:39 2011 -0500 drm/radeon/kms: add quirk for Mac Radeon HD 2600 card commit f598aa7593427ffe3a61e7767c34bd695a5e7ed0 upstream. Reported-by: 屋国遥 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5ed523f5677013b7d71cd1fe91b070602d4cdb45 Author: Shawn Guo Date: Wed Jan 5 21:13:09 2011 +0000 net/fec: fix MMFR_OP type in fec_enet_mdio_write commit 862f0982eadcea0e114576c57ea426d3d51a69a6 upstream. FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in a mdio write operation. It's probably a typo introduced by commit: e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8 netdev/fec.c: add phylib supporting to enable carrier detection (v2) Signed-off-by: Shawn Guo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bddab9a6e92697dbef442a23c56722896e8d427b Author: Mike Snitzer Date: Thu Jan 13 19:59:46 2011 +0000 dm mpath: disable blk_abort_queue commit 09c9d4c9b6a2b5909ae3c6265e4cd3820b636863 upstream. Revert commit 224cb3e981f1b2f9f93dbd49eaef505d17d894c2 dm: Call blk_abort_queue on failed paths Multipath began to use blk_abort_queue() to allow for lower latency path deactivation. This was found to cause list corruption: the cmd gets blk_abort_queued/timedout run on it and the scsi eh somehow is able to complete and run scsi_queue_insert while scsi_request_fn is still trying to process the request. https://www.redhat.com/archives/dm-devel/2010-November/msg00085.html Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Cc: Mike Anderson Cc: Mike Christie Signed-off-by: Greg Kroah-Hartman commit 1ca36e525b4f1c7d0cce6bba991e837fcb716bf4 Author: Mike Snitzer Date: Thu Jan 13 19:53:46 2011 +0000 dm: dont take i_mutex to change device size commit c217649bf2d60ac119afd71d938278cffd55962b upstream. No longer needlessly hold md->bdev->bd_inode->i_mutex when changing the size of a DM device. This additional locking is unnecessary because i_size_write() is already protected by the existing critical section in dm_swap_table(). DM already has a reference on md->bdev so the associated bd_inode may be changed without lifetime concerns. A negative side-effect of having held md->bdev->bd_inode->i_mutex was that a concurrent DM device resize and flush (via fsync) would deadlock. Dropping md->bdev->bd_inode->i_mutex eliminates this potential for deadlock. The following reproducer no longer deadlocks: https://www.redhat.com/archives/dm-devel/2009-July/msg00284.html Signed-off-by: Mike Snitzer Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit b2420c31459a69d90a89e1b2e7484bcea930fb35 Author: Amitkumar Karwar Date: Tue Jan 11 16:14:24 2011 -0800 ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro commit 8d661f1e462d50bd83de87ee628aaf820ce3c66c upstream. It is defined in include/linux/ieee80211.h. As per IEEE spec. bit6 to bit15 in block ack parameter represents buffer size. So the bitmask should be 0xFFC0. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Reviewed-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 267b02bf3ccda4ba557e56e4cbc827cef74e036f Author: Matthew Garrett Date: Thu Oct 21 17:42:40 2010 -0400 tpm: Autodetect itpm devices commit 3f0d3d016d89a5efb8b926d4707eb21fa13f3d27 upstream. Some Lenovos have TPMs that require a quirk to function correctly. This can be autodetected by checking whether the device has a _HID of INTC0102. This is an invalid PNPid, and as such is discarded by the pnp layer - however it's still present in the ACPI code, so we can pull it out that way. This means that the quirk won't be automatically applied on non-ACPI systems, but without ACPI we don't have any way to identify the chip anyway so I don't think that's a great concern. Signed-off-by: Matthew Garrett Acked-by: Rajiv Andrade Tested-by: Jiri Kosina Tested-by: Andy Isaacson Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 1d91afd8b1854d363d88cf95dafeaffff6f8bb08 Author: Eric Paris Date: Thu Dec 2 16:13:40 2010 -0500 SELinux: do not compute transition labels on mountpoint labeled filesystems commit 415103f9932d45f7927f4b17e3a9a13834cdb9a1 upstream. selinux_inode_init_security computes transitions sids even for filesystems that use mount point labeling. It shouldn't do that. It should just use the mount point label always and no matter what. This causes 2 problems. 1) it makes file creation slower than it needs to be since we calculate the transition sid and 2) it allows files to be created with a different label than the mount point! # id -Z staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 # sesearch --type --class file --source sysadm_t --target tmp_t Found 1 semantic te rules: type_transition sysadm_t tmp_t : file user_tmp_t; # mount -o loop,context="system_u:object_r:tmp_t:s0" /tmp/fs /mnt/tmp # ls -lZ /mnt/tmp drwx------. root root system_u:object_r:tmp_t:s0 lost+found # touch /mnt/tmp/file1 # ls -lZ /mnt/tmp -rw-r--r--. root root staff_u:object_r:user_tmp_t:s0 file1 drwx------. root root system_u:object_r:tmp_t:s0 lost+found Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t labeled file! Signed-off-by: Eric Paris Reviewed-by: Reviewed-by: James Morris Signed-off-by: Greg Kroah-Hartman commit b38c0639474250cb4cdb91a36a2a2f781305cdcc Author: Eric Paris Date: Thu Dec 16 11:46:51 2010 -0500 SELinux: define permissions for DCB netlink messages commit 350e4f31e0eaf56dfc3b328d24a11bdf42a41fb8 upstream. Commit 2f90b865 added two new netlink message types to the netlink route socket. SELinux has hooks to define if netlink messages are allowed to be sent or received, but it did not know about these two new message types. By default we allow such actions so noone likely noticed. This patch adds the proper definitions and thus proper permissions enforcement. Signed-off-by: Eric Paris Cc: James Morris Signed-off-by: Greg Kroah-Hartman commit de79143f1a7d8bc3340d982813ccc013cca01ccc Author: David Howells Date: Wed Dec 22 16:24:13 2010 +0000 KEYS: Don't call up_write() if __key_link_begin() returns an error commit 3fc5e98d8cf85e0d77fc597b49e9268dff67400e upstream. In construct_alloc_key(), up_write() is called in the error path if __key_link_begin() fails, but this is incorrect as __key_link_begin() only returns with the nominated keyring locked if it returns successfully. Without this patch, you might see the following in dmesg: ===================================== [ BUG: bad unlock balance detected! ] ------------------------------------- mount.cifs/5769 is trying to release lock (&key->sem) at: [] request_key_and_link+0x263/0x3fc but there are no more locks to release! other info that might help us debug this: 3 locks held by mount.cifs/5769: #0: (&type->s_umount_key#41/1){+.+.+.}, at: [] sget+0x278/0x3e7 #1: (&ret_buf->session_mutex){+.+.+.}, at: [] cifs_get_smb_ses+0x35a/0x443 [cifs] #2: (root_key_user.cons_lock){+.+.+.}, at: [] request_key_and_link+0x10a/0x3fc stack backtrace: Pid: 5769, comm: mount.cifs Not tainted 2.6.37-rc6+ #1 Call Trace: [] ? request_key_and_link+0x263/0x3fc [] print_unlock_inbalance_bug+0xca/0xd5 [] lock_release_non_nested+0xc1/0x263 [] ? request_key_and_link+0x263/0x3fc [] ? request_key_and_link+0x263/0x3fc [] lock_release+0x17d/0x1a4 [] up_write+0x23/0x3b [] request_key_and_link+0x263/0x3fc [] ? cifs_get_spnego_key+0x61/0x21f [cifs] [] request_key+0x41/0x74 [] cifs_get_spnego_key+0x200/0x21f [cifs] [] CIFS_SessSetup+0x55d/0x1273 [cifs] [] cifs_setup_session+0x90/0x1ae [cifs] [] cifs_get_smb_ses+0x37f/0x443 [cifs] [] cifs_mount+0x1aa1/0x23f3 [cifs] [] ? alloc_debug_processing+0xdb/0x120 [] ? cifs_get_spnego_key+0x1ef/0x21f [cifs] [] cifs_do_mount+0x165/0x2b3 [cifs] [] vfs_kern_mount+0xaf/0x1dc [] do_kern_mount+0x4d/0xef [] do_mount+0x6f4/0x733 [] sys_mount+0x88/0xc2 [] system_call_fastpath+0x16/0x1b Reported-by: Jeff Layton Signed-off-by: David Howells Reviewed-and-Tested-by: Jeff Layton Signed-off-by: Linus Torvalds Cc: James Morris Signed-off-by: Greg Kroah-Hartman commit 9c63b4bcf5832c61b458fee328715c0c1ffd5052 Author: Stefan Berger Date: Tue Jan 11 14:37:29 2011 -0500 tpm_tis: Use timeouts returned from TPM commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. The current TPM TIS driver in git discards the timeout values returned from the TPM. The check of the response packet needs to consider that the return_code field is 0 on success and the size of the expected packet is equivalent to the header size + u32 length indicator for the TPM_GetCapability() result + 3 timeout indicators of type u32. I am also adding a sysfs entry 'timeouts' showing the timeouts that are being used. Signed-off-by: Stefan Berger Tested-by: Guillaume Chazarain Signed-off-by: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman commit ac88c7bacc068be260de461037174ba140a2e21a Author: Rajiv Andrade Date: Fri Nov 12 22:30:02 2010 +0100 TPM: Long default timeout fix commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 43a1ff7eb4d2e51f3852bed286376635e0628c9f Author: Ryusuke Konishi Date: Fri Jan 21 16:40:31 2011 +0900 nilfs2: fix crash after one superblock became unavailable commit 0ca7a5b9ac5d301845dd6382ff25a699b6263a81 upstream. Fixes the following kernel oops in nilfs_setup_super() which could arise if one of two super-blocks is unavailable. > BUG: unable to handle kernel NULL pointer dereference at (null) > Pid: 3529, comm: mount.nilfs2 Not tainted 2.6.37 #1 / > EIP: 0060:[] EFLAGS: 00010202 CPU: 3 > EIP is at memcpy+0xc/0x1b > Call Trace: > [] ? nilfs_setup_super+0x6c/0xa5 [nilfs2] > [] ? nilfs_get_root_dentry+0x81/0xcb [nilfs2] > [] ? nilfs_mount+0x4f9/0x62c [nilfs2] > [] ? kstrdup+0x36/0x3f > [] ? nilfs_mount+0x0/0x62c [nilfs2] > [] ? vfs_kern_mount+0x4d/0x12c > [] ? get_fs_type+0x76/0x8f > [] ? do_kern_mount+0x33/0xbf > [] ? do_mount+0x2ed/0x714 > [] ? copy_mount_options+0x28/0xfc > [] ? sys_mount+0x72/0xaf > [] ? syscall_call+0x7/0xb Reported-by: Wakko Warner Signed-off-by: Ryusuke Konishi Tested-by: Wakko Warner LKML-Reference: <20110121024918.GA29598@animx.eu.org> Signed-off-by: Greg Kroah-Hartman commit f967dc0329beba814f815ab411ea1000b7b8dec1 Author: Joerg Roedel Date: Fri Jan 14 10:10:19 2011 -0200 KVM: MMU: Fix 32 bit legacy paging with NPT commit f87f928882d080eaec8b0d76aecff003d664697d upstream. This patch fixes 32 bit legacy paging with NPT enabled. The mmu_check_root call on the top-level of the loop causes root_gfn to take values (in the tdp_enabled path) which are outside of guest memory. So the mmu_check_root call fails at some point in the loop interation causing the guest to tiple-fault. This patch changes the mmu_check_root calls to the places where they are really necessary. As a side-effect it introduces a check for the root of a pae page table too. Signed-off-by: Joerg Roedel Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit e9d2581219cb776a9b6eeab9042584e9d5c3b046 Author: Avi Kivity Date: Fri Jan 14 10:10:18 2011 -0200 KVM: MMU: Fix incorrect direct gfn for unpaged mode shadow commit c093b8b46c5f0dd12d799f0d6a3b579863df72f6 upstream. We use the physical address instead of the base gfn for the four PAE page directories we use in unpaged mode. When the guest accesses an address above 1GB that is backed by a large host page, a BUG_ON() in kvm_mmu_set_gfn() triggers. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=21962 Reported-and-tested-by: Nicolas Prochazka Signed-off-by: Avi Kivity Cc: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 295c639bff96e344913cd99118eecadf211e2e68 Author: Avi Kivity Date: Fri Jan 14 10:10:17 2011 -0200 KVM: i8259: initialize isr_ack commit a0272630bb594b4eac03a79e77957df7dad8eade upstream. isr_ack is never initialized. So, until the first PIC reset, interrupts may fail to be injected. This can cause Windows XP to fail to boot, as reported in the fallout from the fix to https://bugzilla.kernel.org/show_bug.cgi?id=21962. Reported-and-tested-by: Nicolas Prochazka Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 823c5c79a5da97b6f4314be7d0f350fdc19df9b7 Author: Chris Mason Date: Mon Feb 7 19:21:48 2011 -0500 md_make_request: don't touch the bio after calling make_request commit e91ece5590b3c728624ab57043fc7a05069c604a upstream. md_make_request was calling bio_sectors() for part_stat_add after it was calling the make_request function. This is bad because the make_request function can free the bio and because the bi_size field can change around. The fix here was suggested by Jens Axboe. It saves the sector count before the make_request call. I hit this with CONFIG_DEBUG_PAGEALLOC turned on while trying to break his pretty fusionio card. Signed-off-by: Chris Mason Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 4f8fa9bc7226ba1581e63e3ff1b583f5c1026edd Author: Tejun Heo Date: Sun Jan 9 17:48:20 2011 -0500 pata_mpc52xx: inherit from ata_bmdma_port_ops commit 77c5fd19075d299fe820bb59bb21b0b113676e20 upstream. pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which triggers BUG_ON() when a DMA command is issued. Fix it. Signed-off-by: Tejun Heo Reported-by: Roman Fietze Cc: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 0addbdd392125780ac65bcd9dcf69eae2afb9c01 Author: NeilBrown Date: Fri Jan 14 09:14:34 2011 +1100 md: Fix removal of extra drives when converting RAID6 to RAID5 commit bf2cb0dab8c97f00a71875d9b13dbac17a2f47ca upstream. When a RAID6 is converted to a RAID5, the extra drive should be discarded. However it isn't due to a typo in a comparison. This bug was introduced in commit e93f68a1fc6 in 2.6.35-rc4 and is suitable for any -stable since than. As the extra drive is not removed, the 'degraded' counter is wrong and so the RAID5 will not respond correctly to a subsequent failure. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 7896fe54a75c5bfd8dfed08d98cb7e15896e3749 Author: NeilBrown Date: Fri Jan 14 09:14:33 2011 +1100 md: Ensure no IO request to get md device before it is properly initialised. commit 0ca69886a8273ac1350143d562280bfcbe4760dc upstream. When an md device is in the process of coming on line it is possible for an IO request (typically a partition table probe) to get through before the array is fully initialised, which can cause unexpected behaviour (e.g. a crash). So explicitly record when the array is ready for IO and don't allow IO through until then. There is no possibility for a similar problem when the array is going off-line as there must only be one 'open' at that time, and it is busy off-lining the array and so cannot send IO requests. So no memory barrier is needed in md_stop() This has been a bug since commit 409c57f3801 in 2.6.30 which introduced md_make_request. Before then, each personality would register its own make_request_fn when it was ready. This is suitable for any stable kernel from 2.6.30.y onwards. Signed-off-by: NeilBrown Reported-by: "Hawrylewicz Czarnowski, Przemyslaw" Signed-off-by: Greg Kroah-Hartman commit a53775f3a5b7cfdca47560285bf87616a808f25b Author: NeilBrown Date: Fri Jan 14 09:13:53 2011 +1100 md: fix regression resulting in delays in clearing bits in a bitmap commit 6c9879101442b08581e8a0e3ae6b7f643a78fd63 upstream. commit 589a594be1fb (2.6.37-rc4) fixed a problem were md_thread would sometimes call the ->run function at a bad time. If an error is detected during array start up after the md_thread has been started, the md_thread is killed. This resulted in the ->run function being called once. However the array may not be in a state that it is safe to call ->run. However the fix imposed meant that ->run was not called on a timeout. This means that when an array goes idle, bitmap bits do not get cleared promptly. While the array is busy the bits will still be cleared when appropriate so this is not very serious. There is no risk to data. Change the test so that we only avoid calling ->run when the thread is being stopped. This more explicitly addresses the problem situation. This is suitable for 2.6.37-stable and any -stable kernel to which 589a594be1fb was applied. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit f03114dc3b5ba8d9c271046f45c17aecb0a29402 Author: NeilBrown Date: Wed Jan 12 09:03:35 2011 +1100 md: fix regression with re-adding devices to arrays with no metadata commit bf572541ab44240163eaa2d486b06f306a31d45a upstream. Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were re-added when they shouldn't be but caused a regression in a less common case that means sometimes devices cannot be re-added when they should be. In particular, when re-adding a device to an array without metadata we should always access the device, but after the above commit we didn't. This patch sets the In_sync flag in that case so that the re-add succeeds. This patch is suitable for any -stable kernel to which 1a855a0606 was applied. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 44c73d2ededd2deed83d74163cf49f60910f0f95 Author: Anton Blanchard Date: Thu Jan 20 14:44:33 2011 -0800 kernel/smp.c: fix smp_call_function_many() SMP race commit 6dc19899958e420a931274b94019e267e2396d3e upstream. I noticed a failure where we hit the following WARN_ON in generic_smp_call_function_interrupt: if (!cpumask_test_and_clear_cpu(cpu, data->cpumask)) continue; data->csd.func(data->csd.info); refs = atomic_dec_return(&data->refs); WARN_ON(refs < 0); <------------------------- We atomically tested and cleared our bit in the cpumask, and yet the number of cpus left (ie refs) was 0. How can this be? It turns out commit 54fdade1c3332391948ec43530c02c4794a38172 ("generic-ipi: make struct call_function_data lockless") is at fault. It removes locking from smp_call_function_many and in doing so creates a rather complicated race. The problem comes about because: - The smp_call_function_many interrupt handler walks call_function.queue without any locking. - We reuse a percpu data structure in smp_call_function_many. - We do not wait for any RCU grace period before starting the next smp_call_function_many. Imagine a scenario where CPU A does two smp_call_functions back to back, and CPU B does an smp_call_function in between. We concentrate on how CPU C handles the calls: CPU A CPU B CPU C CPU D smp_call_function smp_call_function_interrupt walks call_function.queue sees data from CPU A on list smp_call_function smp_call_function_interrupt walks call_function.queue sees (stale) CPU A on list smp_call_function int clears last ref on A list_del_rcu, unlock smp_call_function reuses percpu *data A data->cpumask sees and clears bit in cpumask might be using old or new fn! decrements refs below 0 set data->refs (too late!) The important thing to note is since the interrupt handler walks a potentially stale call_function.queue without any locking, then another cpu can view the percpu *data structure at any time, even when the owner is in the process of initialising it. The following test case hits the WARN_ON 100% of the time on my PowerPC box (having 128 threads does help :) #include #include #define ITERATIONS 100 static void do_nothing_ipi(void *dummy) { } static void do_ipis(struct work_struct *dummy) { int i; for (i = 0; i < ITERATIONS; i++) smp_call_function(do_nothing_ipi, NULL, 1); printk(KERN_DEBUG "cpu %d finished\n", smp_processor_id()); } static struct work_struct work[NR_CPUS]; static int __init testcase_init(void) { int cpu; for_each_online_cpu(cpu) { INIT_WORK(&work[cpu], do_ipis); schedule_work_on(cpu, &work[cpu]); } return 0; } static void __exit testcase_exit(void) { } module_init(testcase_init) module_exit(testcase_exit) MODULE_LICENSE("GPL"); MODULE_AUTHOR("Anton Blanchard"); I tried to fix it by ordering the read and the write of ->cpumask and ->refs. In doing so I missed a critical case but Paul McKenney was able to spot my bug thankfully :) To ensure we arent viewing previous iterations the interrupt handler needs to read ->refs then ->cpumask then ->refs _again_. Thanks to Milton Miller and Paul McKenney for helping to debug this issue. [miltonm@bga.com: add WARN_ON and BUG_ON, remove extra read of refs before initial read of mask that doesn't help (also noted by Peter Zijlstra), adjust comments, hopefully clarify scenario ] [miltonm@bga.com: remove excess tests] Signed-off-by: Anton Blanchard Signed-off-by: Milton Miller Cc: Ingo Molnar Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ed8f1a28a0fbe533047de331ae97b87ee1903828 Author: David Dillow Date: Thu Jan 20 14:44:22 2011 -0800 fs/direct-io.c: don't try to allocate more than BIO_MAX_PAGES in a bio commit 20d9600cb407b0b55fef6ee814b60345c6f58264 upstream. When using devices that support max_segments > BIO_MAX_PAGES (256), direct IO tries to allocate a bio with more pages than allowed, which leads to an oops in dio_bio_alloc(). Clamp the request to the supported maximum, and change dio_bio_alloc() to reflect that bio_alloc() will always return a bio when called with __GFP_WAIT and a valid number of vectors. [akpm@linux-foundation.org: remove redundant BUG_ON()] Signed-off-by: David Dillow Reviewed-by: Jeff Moyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4e3e37b58d6cba97d9d9f5d9532d587030fcc648 Author: Randy Dunlap Date: Thu Jan 20 14:44:31 2011 -0800 backlight: fix 88pm860x_bl macro collision commit 2550326ac7a062fdfc204f9a3b98bdb9179638fc upstream. Fix collision with kernel-supplied #define: drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definition Signed-off-by: Randy Dunlap Cc: Haojian Zhuang Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 49aaedcac826772e1054c8a5ec9fb9d0af45df8c Author: Michael Büsch Date: Fri Feb 4 23:34:45 2011 +0100 ssb-pcmcia: Fix parsing of invariants tuples commit dd3cb633078fb12e06ce6cebbdfbf55a7562e929 upstream. This fixes parsing of the device invariants (MAC address) for PCMCIA SSB devices. ssb_pcmcia_do_get_invariants expects an iv pointer as data argument. Tested-by: dylan cristiani Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 71a18194814f64021ec3dfc5a9b07d0eee2a1583 Author: Corey Minyard Date: Thu Feb 10 16:08:38 2011 -0600 char/ipmi: fix OOPS caused by pnp_unregister_driver on unregistered driver commit d2478521afc20227658a10a8c5c2bf1a2aa615b3 upstream. This patch fixes an OOPS triggered when calling modprobe ipmi_si a second time after the first modprobe returned without finding any ipmi devices. This can happen if you reload the module after having the first module load fail. The driver was not deregistering from PNP in that case. Peter Huewe originally reported this patch and supplied a fix, I have a different patch based on Linus' suggestion that cleans things up a bit more. Cc: openipmi-developer@lists.sourceforge.net Reviewed-by: Peter Huewe Cc: Randy Dunlap Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 91bbb90c3b953b03fae72a22ae7a0713a48b3dba Author: Marcin Slusarz Date: Fri Jan 28 11:00:33 2011 -0500 watchdog: Don't change watchdog state on read of sysctl commit 9ffdc6c37df131f89d52001e0ef03091b158826f upstream. Signed-off-by: Marcin Slusarz [ add {}'s to fix a warning ] Signed-off-by: Don Zickus Cc: Peter Zijlstra Cc: Frederic Weisbecker LKML-Reference: <1296230433-6261-3-git-send-email-dzickus@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 615563d11619a5df5c95577236888434c78e54a9 Author: Marcin Slusarz Date: Fri Jan 28 11:00:32 2011 -0500 watchdog: Fix sysctl consistency commit 397357666de6b5b6adb5fa99f9758ec8cf30ac34 upstream. If it was not possible to enable watchdog for any cpu, switch watchdog_enabled back to 0, because it's visible via kernel.watchdog sysctl. Signed-off-by: Marcin Slusarz Signed-off-by: Don Zickus Cc: Peter Zijlstra Cc: Frederic Weisbecker LKML-Reference: <1296230433-6261-2-git-send-email-dzickus@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 9b65e47537df40b66fdb50e17c3c50cc121c6254 Author: Guy Martin Date: Mon Dec 6 16:48:04 2010 +0100 parisc : Remove broken line wrapping handling pdc_iodc_print() commit fbea668498e93bb38ac9226c7af9120a25957375 upstream. Remove the broken line wrapping handling in pdc_iodc_print(). It is broken in 3 ways : - It doesn't keep track of the current screen position, it just assumes that the new buffer will be printed at the begining of the screen. - It doesn't take in account that non printable characters won't increase the current position on the screen. - And last but not least, it triggers a kernel panic if a backspace is the first char in the provided buffer : Backtrace: [<0000000040128ec4>] pdc_console_write+0x44/0x78 [<0000000040128f18>] pdc_console_tty_write+0x20/0x38 [<000000004032f1ac>] n_tty_write+0x2a4/0x550 [<000000004032b158>] tty_write+0x1e0/0x2d8 [<00000000401bb420>] vfs_write+0xb8/0x188 [<00000000401bb630>] sys_write+0x68/0xb8 [<0000000040104eb8>] syscall_exit+0x0/0x14 Most terminals handle the line wrapping just fine. I've confirmed that it works correctly on a C8000 with both vga and serial output. Signed-off-by: Guy Martin Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 40688b6476e61cedd9d6ca5d2e1078c7e35cd7c0 Author: Stefan Richter Date: Sat Jan 15 18:19:48 2011 +0100 firewire: core: fix unstable I/O with Canon camcorder commit 6044565af458e7fa6e748bff437ecc49dea88d79 upstream. Regression since commit 10389536742c, "firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder": The camcorder Canon MV5i generates lots of bus resets when asynchronous requests are sent to it (e.g. Config ROM read requests or FCP Command write requests) if the camcorder is not root node. This causes drop- outs in videos or makes the camcorder entirely inaccessible. https://bugzilla.redhat.com/show_bug.cgi?id=633260 Fix this by allowing any Canon device, even if it is a pre-1394a IRM like MV5i are, to remain root node (if it is at least Cycle Master capable). With the FireWire controller cards that I tested, MV5i always becomes root node when plugged in and left to its own devices. Reported-by: Ralf Lange Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 1ad94a4f74fd33df13760c679e8edba1b77ab9ad Author: Benjamin Herrenschmidt Date: Thu Jan 20 20:35:23 2011 +0000 powerpc: Fix some 6xx/7xxx CPU setup functions commit 1f1936ff3febf38d582177ea319eaa278f32c91f upstream. Some of those functions try to adjust the CPU features, for example to remove NAP support on some revisions. However, they seem to use r5 as an index into the CPU table entry, which might have been right a long time ago but no longer is. r4 is the right register to use. This probably caused some off behaviours on some PowerMac variants using 750cx or 7455 processor revisions. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 756917be0bc2eab26ce39d20dc594e1c01310188 Author: Anton Blanchard Date: Sat Jan 29 12:37:16 2011 +0000 powerpc/numa: Fix bug in unmap_cpu_from_node commit 429f4d8d20b91e4a6c239f951c06a56a6ac22957 upstream. When converting to the new cpumask code I screwed up: - if (cpu_isset(cpu, numa_cpumask_lookup_table[node])) { - cpu_clear(cpu, numa_cpumask_lookup_table[node]); + if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) { + cpumask_set_cpu(cpu, node_to_cpumask_map[node]); This was introduced in commit 25863de07af9 (powerpc/cpumask: Convert NUMA code to new cpumask API) Fix it. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3ca30e408a08f9b902d4d7d0422be498584cb966 Author: Anton Blanchard Date: Thu Oct 21 00:52:12 2010 +0000 powerpc: Fix hcall tracepoint recursion commit 57cdfdf829a850a317425ed93c6a576c9ee6329c upstream. Spinlocks on shared processor partitions use H_YIELD to notify the hypervisor we are waiting on another virtual CPU. Unfortunately this means the hcall tracepoints can recurse. The patch below adds a percpu depth and checks it on both the entry and exit hcall tracepoints. Signed-off-by: Anton Blanchard Acked-by: Steven Rostedt Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 1caf470a3c4ab570b38a6e7c339e06f18909ef98 Author: Timur Tabi Date: Fri Dec 3 10:52:14 2010 -0600 powerpc/85xx: fix compatible properties of the P1022DS DMA nodes used for audio commit b2e0861e51f2961954330dcafe6d148ee3ab5cff upstream. In order to prevent the fsl_dma driver from claiming the DMA channels that the P1022DS audio driver needs, the compatible properties for those nodes must say "fsl,ssi-dma-channel" instead of "fsl,eloplus-dma-channel". Signed-off-by: Timur Tabi Signed-off-by: Kumar Gala Signed-off-by: Greg Kroah-Hartman commit e4bbb71290c897c349f9bed3a92907be95e16656 Author: Justin TerAvest Date: Wed Feb 9 14:20:03 2011 +0100 cfq-iosched: Don't wait if queue already has requests. commit 02a8f01b5a9f396d0327977af4c232d0f94c45fd upstream. Commit 7667aa0630407bc07dc38dcc79d29cc0a65553c1 added logic to wait for the last queue of the group to become busy (have at least one request), so that the group does not lose out for not being continuously backlogged. The commit did not check for the condition that the last queue already has some requests. As a result, if the queue already has requests, wait_busy is set. Later on, cfq_select_queue() checks the flag, and decides that since the queue has a request now and wait_busy is set, the queue is expired. This results in early expiration of the queue. This patch fixes the problem by adding a check to see if queue already has requests. If it does, wait_busy is not set. As a result, time slices do not expire early. The queues with more than one request are usually buffered writers. Testing shows improvement in isolation between buffered writers. Signed-off-by: Justin TerAvest Reviewed-by: Gui Jianfeng Acked-by: Vivek Goyal Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5648b203ebfce5b9b26bc4a95d4072f30d8f8f66 Author: David Miller Date: Sun Feb 13 16:37:07 2011 -0800 klist: Fix object alignment on 64-bit. commit 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505 upstream. Commit c0e69a5bbc6f ("klist.c: bit 0 in pointer can't be used as flag") intended to make sure that all klist objects were at least pointer size aligned, but used the constant "4" which only works on 32-bit. Use "sizeof(void *)" which is correct in all cases. Signed-off-by: David S. Miller Acked-by: Jesper Nilsson Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c04eb9683fbb6374275309b859fcbf02e1db2c78 Author: Mel Gorman Date: Thu Jan 13 15:45:41 2011 -0800 mm: page allocator: adjust the per-cpu counter threshold when memory is low commit 88f5acf88ae6a9778f6d25d0d5d7ec2d57764a97 upstream. Commit aa45484 ("calculate a better estimate of NR_FREE_PAGES when memory is low") noted that watermarks were based on the vmstat NR_FREE_PAGES. To avoid synchronization overhead, these counters are maintained on a per-cpu basis and drained both periodically and when a threshold is above a threshold. On large CPU systems, the difference between the estimate and real value of NR_FREE_PAGES can be very high. The system can get into a case where pages are allocated far below the min watermark potentially causing livelock issues. The commit solved the problem by taking a better reading of NR_FREE_PAGES when memory was low. Unfortately, as reported by Shaohua Li this accurate reading can consume a large amount of CPU time on systems with many sockets due to cache line bouncing. This patch takes a different approach. For large machines where counter drift might be unsafe and while kswapd is awake, the per-cpu thresholds for the target pgdat are reduced to limit the level of drift to what should be a safe level. This incurs a performance penalty in heavy memory pressure by a factor that depends on the workload and the machine but the machine should function correctly without accidentally exhausting all memory on a node. There is an additional cost when kswapd wakes and sleeps but the event is not expected to be frequent - in Shaohua's test case, there was one recorded sleep and wake event at least. To ensure that kswapd wakes up, a safe version of zone_watermark_ok() is introduced that takes a more accurate reading of NR_FREE_PAGES when called from wakeup_kswapd, when deciding whether it is really safe to go back to sleep in sleeping_prematurely() and when deciding if a zone is really balanced or not in balance_pgdat(). We are still using an expensive function but limiting how often it is called. When the test case is reproduced, the time spent in the watermark functions is reduced. The following report is on the percentage of time spent cumulatively spent in the functions zone_nr_free_pages(), zone_watermark_ok(), __zone_watermark_ok(), zone_watermark_ok_safe(), zone_page_state_snapshot(), zone_page_state(). vanilla 11.6615% disable-threshold 0.2584% David said: : We had to pull aa454840 "mm: page allocator: calculate a better estimate : of NR_FREE_PAGES when memory is low and kswapd is awake" from 2.6.36 : internally because tests showed that it would cause the machine to stall : as the result of heavy kswapd activity. I merged it back with this fix as : it is pending in the -mm tree and it solves the issue we were seeing, so I : definitely think this should be pushed to -stable (and I would seriously : consider it for 2.6.37 inclusion even at this late date). Signed-off-by: Mel Gorman Reported-by: Shaohua Li Reviewed-by: Christoph Lameter Tested-by: Nicolas Bareil Cc: David Rientjes Cc: Kyle McMartin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 826099cd9ae4186b8907d7ed5ec5fc450ae83545 Author: Sonic Zhang Date: Tue Jan 11 22:39:35 2011 -0500 mmc: bfin_sdh: fix alloc size for private data commit a34650f0f1ca589cda09c48cb62baf15e680a247 upstream. The bfin_sdh driver allocates the wrong size for the private data in the mmc_host. The first parameter of mmc_alloc_host should be the size of the local driver struct rather than the common mmc_host. Signed-off-by: Sonic Zhang Signed-off-by: Mike Frysinger Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit ca4cf61868e2bafeeb9f320e5da9b431e0f3aabd Author: KAMEZAWA Hiroyuki Date: Tue Jan 25 15:07:27 2011 -0800 memcg: fix account leak at failure of memsw acconting commit 01c88e2d6b7330c0cc5867fe2297e7d826e1337d upstream. Commit 4b53433468 ("memcg: clean up try_charge main loop") removes a cancel of charge at case: memory charge-> success. mem+swap charge-> failure. This leaks usage of memory. Fix it. Signed-off-by: KAMEZAWA Hiroyuki Reviewed-by: Johannes Weiner Acked-by: Daisuke Nishimura Cc: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6880ae16eeb4d4f34d9d6090fa8bc0beb9c6ed69 Author: Russell King Date: Sun Jan 30 11:21:05 2011 +0000 ARM: initrd: disable initrd if passed address overlaps reserved region commit b0a2679d27408d97ce31e5f800b44227d3388b84 upstream. Disable the initrd if the passed address already overlaps the reserved region. This avoids oopses on Netwinders when NeTTrom tells the kernel that an initrd is located at mem+4MB, but this overlaps the BSS, resulting in the kernels in-use BSS being freed. This should be applied to v2.6.37-stable. Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ceb615bfeb0a612b13a7d58b4e09194b92e85fbb Author: Kacper Kornet Date: Sat Jan 29 00:21:04 2011 +0100 Fix prlimit64 for suid/sgid processes commit aa5bd67dcfdf9af34c7fa36ebc87d4e1f7e91873 upstream. Since check_prlimit_permission always fails in the case of SUID/GUID processes, such processes are not able to read or set their own limits. This commit changes this by assuming that process can always read/change its own limits. Signed-off-by: Kacper Kornet Acked-by: Jiri Slaby Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fd70b698a14e58cdd9f35715f9594a9084ac54c0 Author: Don Skidmore Date: Tue Jan 18 22:53:47 2011 +0000 ixgbe: fix for 82599 erratum on Header Splitting commit a124339ad28389093ed15eca990d39c51c5736cc upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by: Don Skidmore Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit eb77d7cb03db898f8c8d2a3a149ab2aacad478e0 Author: Tim Deegan Date: Thu Feb 10 08:50:41 2011 +0000 fix jiffy calculations in calibrate_delay_direct to handle overflow commit 70a062286b9dfcbd24d2e11601aecfead5cf709a upstream. Fixes a hang when booting as dom0 under Xen, when jiffies can be quite large by the time the kernel init gets this far. Signed-off-by: Tim Deegan [jbeulich@novell.com: !time_after() -> time_before_eq() as suggested by Jiri Slaby] Signed-off-by: Jan Beulich Cc: Jiri Slaby Cc: Jeremy Fitzhardinge Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 17ed50411002357e7d97b293e4977ea3b19803b1 Author: Suresh Siddha Date: Wed Feb 2 17:02:55 2011 -0800 x86, mtrr: Avoid MTRR reprogramming on BP during boot on UP platforms commit f7448548a9f32db38f243ccd4271617758ddfe2c upstream. Markus Kohn ran into a hard hang regression on an acer aspire 1310, when acpi is enabled. git bisect showed the following commit as the bad one that introduced the boot regression. commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3 Author: Suresh Siddha Date: Wed Aug 19 18:05:36 2009 -0700 x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init Because of the UP configuration of that platform, native_smp_prepare_cpus() bailed out (in smp_sanity_check()) before doing the set_mtrr_aps_delayed_init() Further down the boot path, native_smp_cpus_done() will call the delayed MTRR initialization for the AP's (mtrr_aps_init()) with mtrr_aps_delayed_init not set. This resulted in the boot processor reprogramming its MTRR's to the values seen during the start of the OS boot. While this is not needed ideally, this shouldn't have caused any side-effects. This is because the reprogramming of MTRR's (set_mtrr_state() that gets called via set_mtrr()) will check if the live register contents are different from what is being asked to write and will do the actual write only if they are different. BP's mtrr state is read during the start of the OS boot and typically nothing would have changed when we ask to reprogram it on BP again because of the above scenario on an UP platform. So on a normal UP platform no reprogramming of BP MTRR MSR's happens and all is well. However, on this platform, bios seems to be modifying the fixed mtrr range registers between the start of OS boot and when we double check the live registers for reprogramming BP MTRR registers. And as the live registers are modified, we end up reprogramming the MTRR's to the state seen during the start of the OS boot. During ACPI initialization, something in the bios (probably smi handler?) don't like this fact and results in a hard lockup. We didn't see this boot hang issue on this platform before the commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3, because only the AP's (if any) will program its MTRR's to the value that BP had at the start of the OS boot. Fix this issue by checking mtrr_aps_delayed_init before continuing further in the mtrr_aps_init(). Now, only AP's (if any) will program its MTRR's to the BP values during boot. Addresses https://bugzilla.novell.com/show_bug.cgi?id=623393 [ By the way, this behavior of the bios modifying MTRR's after the start of the OS boot is not common and the kernel is not prepared to handle this situation well. Irrespective of this issue, during suspend/resume, linux kernel will try to reprogram the BP's MTRR values to the values seen during the start of the OS boot. So suspend/resume might be already broken on this platform for all linux kernel versions. ] Reported-and-bisected-by: Markus Kohn Tested-by: Markus Kohn Signed-off-by: Suresh Siddha Cc: Thomas Renninger Cc: Rafael Wysocki Cc: Venkatesh Pallipadi LKML-Reference: <1296694975.4418.402.camel@sbsiddha-MOBL3.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6066deb3a2ca62e7a990676ca3cc82014844881a Author: Eric W. Biederman Date: Sat Jan 29 14:57:22 2011 +0000 net: Fix ip link add netns oops commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream. Ed Swierk writes: > On 2.6.35.7 > ip link add link eth0 netns 9999 type macvlan > where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang: > [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d > [10663.821917] IP: [] __dev_alloc_name+0x9a/0x170 > [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0 > [10663.821944] Oops: 0000 [#1] SMP > [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [10663.821959] CPU 3 > [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class > [10663.822155] > [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO > [10663.822167] RIP: 0010:[] [] __dev_alloc_name+0x9a/0x170 > [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286 > [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000 > [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000 > [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041 > [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818 > [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000 > [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000 > [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0 > [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0) > [10663.822236] Stack: > [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6 > [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818 > [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413 > [10663.822281] Call Trace: > [10663.822290] [] ? dev_addr_init+0x75/0xb0 > [10663.822298] [] dev_alloc_name+0x43/0x90 > [10663.822307] [