commit 5bf3475919c4544e2b09eacf0a608a632af756e9 Author: Greg Kroah-Hartman Date: Mon Apr 26 07:43:31 2010 -0700 Linux 2.6.32.12 commit ab2406a072a7b02a780c22dc441217eef01848dc Author: Neil Horman Date: Thu Apr 1 07:30:07 2010 +0000 r8169: clean up my printk uglyness commit 93f4d91d879acfcb0ba9c2725e3133fcff2dfd1e upstream. Fix formatting on r8169 printk Brandon Philips noted that I had a spacing issue in my printk for the last r8169 patch that made it quite ugly. Fix that up and add the PFX macro to it as well so it looks like the other r8169 printks Signed-off-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 13739d986b5e4f8f9518617b03ae5b95b0781ce3 Author: Joerg Roedel Date: Wed Apr 7 12:57:35 2010 +0200 x86/gart: Disable GART explicitly before initialization commit 4b83873d3da0704987cb116833818ed96214ee29 upstream. If we boot into a crash-kernel the gart might still be enabled and its caches might be dirty. This can result in undefined behavior later. Fix it by explicitly disabling the gart hardware before initialization and flushing the caches after enablement. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 3b2fc24246311090639173836e551b8a670f4b4b Author: Jan Kiszka Date: Wed Apr 14 16:57:11 2010 +0200 KVM: x86: Fix TSS size check for 16-bit tasks (Cherry-picked from commit e8861cfe2c75bdce36655b64d7ce02c2b31b604d) A 16-bit TSS is only 44 bytes long. So make sure to test for the correct size on task switch. Signed-off-by: Jan Kiszka Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit b7cf825f07d9432ebff7ce58388cd2d948c71811 Author: Sridhar Samudrala Date: Tue Mar 30 16:48:25 2010 -0700 KVM: Increase NR_IOBUS_DEVS limit to 200 (Cherry-picked from commit e80e2a60ff7914dae691345a976c80bbbff3ec74) This patch increases the current hardcoded limit of NR_IOBUS_DEVS from 6 to 200. We are hitting this limit when creating a guest with more than 1 virtio-net device using vhost-net backend. Each virtio-net device requires 2 such devices to service notifications from rx/tx queues. Signed-off-by: Sridhar Samudrala Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 7bb44401c583e795561400230b58d87e9093ac0b Author: Takuya Yoshikawa Date: Mon Apr 12 19:35:35 2010 +0900 KVM: fix the handling of dirty bitmaps to avoid overflows (Cherry-picked from commit 87bf6e7de1134f48681fd2ce4b7c1ec45458cb6d) Int is not long enough to store the size of a dirty bitmap. This patch fixes this problem with the introduction of a wrapper function to calculate the sizes of dirty bitmaps. Note: in mark_page_dirty(), we have to consider the fact that __set_bit() takes the offset as int, not long. Signed-off-by: Takuya Yoshikawa Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 3218dbfc167377d6908390635102917d3b66e5ac Author: Xiao Guangrong Date: Fri Apr 16 16:34:42 2010 +0800 KVM: MMU: fix kvm_mmu_zap_page() and its calling path (Cherry-picked from commit 77662e0028c7c63e34257fda03ff9625c59d939d) This patch fix: - calculate zapped page number properly in mmu_zap_unsync_children() - calculate freeed page number properly kvm_mmu_change_mmu_pages() - if zapped children page it shoud restart hlist walking KVM-Stable-Tag. Signed-off-by: Xiao Guangrong Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit a6c57001ec58dd0d54ca13a5001a5ee63abf3b03 Author: Avi Kivity Date: Thu Apr 8 18:19:35 2010 +0300 KVM: VMX: Save/restore rflags.vm correctly in real mode (Cherry-picked from commit 78ac8b47c566dd6177a3b9b291b756ccb70670b7) Currently we set eflags.vm unconditionally when entering real mode emulation through virtual-8086 mode, and clear it unconditionally when we enter protected mode. The means that the following sequence KVM_SET_REGS (rflags.vm=1) KVM_SET_SREGS (cr0.pe=1) Ends up with rflags.vm clear due to KVM_SET_SREGS triggering enter_pmode(). Fix by shadowing rflags.vm (and rflags.iopl) correctly while in real mode: reads and writes to those bits access a shadow register instead of the actual register. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 6abddbe74fac81296e4d3cee3ba7327c27a96dde Author: Andre Przywara Date: Wed Mar 24 17:46:42 2010 +0100 KVM: allow bit 10 to be cleared in MSR_IA32_MC4_CTL (Cherry-picked from commit 114be429c8cd44e57f312af2bbd6734e5a185b0d) There is a quirk for AMD K8 CPUs in many Linux kernels (see arch/x86/kernel/cpu/mcheck/mce.c:__mcheck_cpu_apply_quirks()) that clears bit 10 in that MCE related MSR. KVM can only cope with all zeros or all ones, so it will inject a #GP into the guest, which will let it panic. So lets add a quirk to the quirk and ignore this single cleared bit. This fixes -cpu kvm64 on all machines and -cpu host on K8 machines with some guest Linux kernels. Signed-off-by: Andre Przywara Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 31e104dc1fbd6e72d8d3e07c38bc77437b82d116 Author: Avi Kivity Date: Thu Mar 11 12:20:03 2010 +0200 KVM: Don't spam kernel log when injecting exceptions due to bad cr writes (Cherry-picked from commit d6a23895aa82353788a1cc5a1d9a1c963465463e) These are guest-triggerable. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 764a47273a858ebd62e560430af19aeed6abcb85 Author: Takuya Yoshikawa Date: Tue Mar 9 14:55:19 2010 +0900 KVM: SVM: Fix memory leaks that happen when svm_create_vcpu() fails (Cherry-picked from commit b7af40433870aa0636932ad39b0c48a0cb319057) svm_create_vcpu() does not free the pages allocated during the creation when it fails to complete the allocations. This patch fixes it. Signed-off-by: Takuya Yoshikawa Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit f5a8ae1ee86c2699e5a693a0acb5e8f4daa00f8b Author: KOSAKI Motohiro Date: Wed Mar 17 09:36:58 2010 +0900 sched: Use proper type in sched_getaffinity() commit 8bc037fb89bb3104b9ae290d18c877624cd7d9cc upstream. Using the proper type fixes the following compiler warning: kernel/sched.c:4850: warning: comparison of distinct pointer types lacks a cast Signed-off-by: KOSAKI Motohiro Cc: torvalds@linux-foundation.org Cc: travis@sgi.com Cc: peterz@infradead.org Cc: drepper@redhat.com Cc: rja@sgi.com Cc: sharyath@in.ibm.com Cc: steiner@sgi.com LKML-Reference: <20100317090046.4C79.A69D9226@jp.fujitsu.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3def5de896ab77232d1cb35fa63dbf627d1db328 Author: Kashyap, Desai Date: Wed Oct 7 11:27:40 2009 +0530 mptspi: Fix for incorrect data underrun errata commit 9b53b39243cf23a0b68eaa16c37ce16eada69a46 upstream. Errata: Certain conditions on the scsi bus may casue the 53C1030 to incorrectly signal a SCSI_DATA_UNDERRUN to the host. Workaround 1: For an Errata on LSI53C1030 When the length of request data and transfer data are different with result of command (READ or VERIFY), DID_SOFT_ERROR is set. Workaround 2: For potential trouble on LSI53C1030. It is checked whether the length of request data is equal to the length of transfer and residual. MEDIUM_ERROR is set by incorrect data. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 8e3400b3d1f568b2ec4349a8e8070c1da867dc96 Author: Kashyap, Desai Date: Wed Oct 7 11:26:54 2009 +0530 mptctl : Remove printk which floods unnecessary messages to var/log/message commit e39e145dfb78d4e20d89139d2576306b4279c126 upstream. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 7ecc5d44a8c9fbcdcda755a9a74463e2b8945c07 Author: Or Gerlitz Date: Thu Nov 12 11:32:27 2009 -0800 IB/iser: Rewrite SG handling for RDMA logic commit c1ccaf2478f84c2665cf57f981db143aa582d646 upstream. After dma-mapping an SG list provided by the SCSI midlayer, iser has to make sure the mapped SG is "aligned for RDMA" in the sense that its possible to produce one mapping in the HCA IOMMU which represents the whole SG. Next, the mapped SG is formatted for registration with the HCA. This patch re-writes the logic that does the above, to make it clearer and simpler. It also fixes a bug in the being aligned for RDMA checks, where a "start" check wasn't done but rather only "end" check. [commit message in RH kernel tree: "Under heavy load, without the patch, the HCA can be programmed to write (corrupt) into pages/location which doesn't belong to the SG associated with the actual I/O and cause a kernel oops."] Signed-off-by: Alexander Nezhinsky Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit a798d8b0cb51bb966763e0feafcbff7097eb3978 Author: Matt Domsch Date: Tue Nov 3 12:05:50 2009 +1100 tpm: autoload tpm_tis based on system PnP IDs commit 31bde71c202722a76686c3cf69a254c8a912275a upstream. The tpm_tis driver already has a list of supported pnp_device_ids. This patch simply exports that list as a MODULE_DEVICE_TABLE() so that the module autoloader will discover and load the module at boottime. Signed-off-by: Matt Domsch Acked-by: Rajiv Andrade Signed-off-by: Andrew Morton Signed-off-by: James Morris Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 9e9be58b68969b25cb9df6805563e9453de927f8 Author: Eric Sandeen Date: Thu Feb 4 23:58:38 2010 -0500 ext4: fix async i/o writes beyond 4GB to a sparse file commit a1de02dccf906faba2ee2d99cac56799bda3b96a upstream. The "offset" member in ext4_io_end holds bytes, not blocks, so ext4_lblk_t is wrong - and too small (u32). This caused the async i/o writes to sparse files beyond 4GB to fail when they wrapped around to 0. Also fix up the type of arguments to ext4_convert_unwritten_extents(), it gets ssize_t from ext4_end_aio_dio_nolock() and ext4_ext_direct_IO(). Reported-by: Giel de Nijs Signed-off-by: Eric Sandeen Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 5d40c8cbd548e3259589d364dd5bf64ab504f147 Author: Eric Sandeen Date: Wed Dec 23 07:58:12 2009 -0500 ext4: flush delalloc blocks when space is low commit c8afb44682fcef6273e8b8eb19fab13ddd05b386 upstream. Creating many small files in rapid succession on a small filesystem can lead to spurious ENOSPC; on a 104MB filesystem: for i in `seq 1 22500`; do echo -n > $SCRATCH_MNT/$i echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i done leads to ENOSPC even though after a sync, 40% of the fs is free again. This is because we reserve worst-case metadata for delalloc writes, and when data is allocated that worst-case reservation is not usually needed. When freespace is low, kicking off an async writeback will start converting that worst-case space usage into something more realistic, almost always freeing up space to continue. This resolves the testcase for me, and survives all 4 generic ENOSPC tests in xfstests. We'll still need a hard synchronous sync to squeeze out the last bit, but this fixes things up to a large degree. Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit b78a38dca6e04634ddc718e315712b45abcf92fd Author: Eric Sandeen Date: Wed Dec 23 07:57:07 2009 -0500 fs-writeback: Add helper function to start writeback if idle commit 17bd55d037a02b04d9119511cfd1a4b985d20f63 upstream. ext4, at least, would like to start pushing on writeback if it starts to get close to ENOSPC when reserving worst-case blocks for delalloc writes. Writing out delalloc data will convert those worst-case predictions into usually smaller actual usage, freeing up space before we hit ENOSPC based on this speculation. Thanks to Jens for the suggestion for the helper function, & the naming help. I've made the helper return status on whether writeback was started even though I don't plan to use it in the ext4 patch; it seems like it would be potentially useful to test this in some cases. Signed-off-by: Eric Sandeen Acked-by: Jan Kara Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit afd9fc6961f208b539d6accd49927639d964be23 Author: Johannes Berg Date: Wed Feb 3 10:22:31 2010 +0100 mac80211: fix deferred hardware scan requests commit c0ce77b8323c1a0d4eeef97caf16c0ea971222a9 upstream. Reinette found the reason for the warnings that happened occasionally when a hw-offloaded scan finished; her description of the problem: mac80211 will defer the handling of scan requests if it is busy with management work at the time. The scan requests are deferred and run after the work has completed. When this occurs there are currently two problems. * The scan request for hardware scan is not fully populated with the band and channels to scan not initialized. * When the scan is queued the state is not correctly updated to reflect that a scan is in progress. The problem here is that when the driver completes the scan and calls ieee80211_scan_completed() a warning will be triggered since mac80211 was not aware that a scan was in progress. The reason is that the queued scan work will start the hw scan right away when the hw_scan_req struct has already been allocated. However, in the first pass it will not have been filled, which happens at the same time as setting the bits. To fix this, simply move the allocation after the pending work test as well, so that the first iteration of the scan work will call __ieee80211_start_scan() even in the hardware scan case. Bug-identified-by: Reinette Chatre Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Cc: Chase Douglas Signed-off-by: Greg Kroah-Hartman commit 33ae7f00cbb6750d1c4b308cdd966794edbe4aef Author: Daniel T Chen Date: Sat Dec 19 18:19:02 2009 -0500 ALSA: hda: Set Front Mic to input vref 50% for Lenovo 3000 Y410 commit e2595322a3a353a59cecd7f57e7aa421ecb02d12 upstream. BugLink: https://bugs.launchpad.net/bugs/479373 The OR has verified with hda-verb that the internal microphone needs VREF50 set for audible capture. Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 47395d161480e6c91b40623a55097b92db026f0f Author: Neil Brown Date: Sun Feb 28 22:01:05 2010 -0500 nfsd: ensure sockets are closed on error commit 301e99ce4a2f42a317129230fd42e6cd874c64b0 upstream. One the changes in commit d7979ae4a "svc: Move close processing to a single place" is: err_delete: - svc_delete_socket(svsk); + set_bit(SK_CLOSE, &svsk->sk_flags); return -EAGAIN; This is insufficient. The recvfrom methods must always call svc_xprt_received on completion so that the socket gets re-queued if there is any more work to do. This particular path did not make that call because it actually destroyed the svsk, making requeue pointless. When the svc_delete_socket was change to just set a bit, we should have added a call to svc_xprt_received, This is the problem that b0401d7253 attempted to fix, incorrectly. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit af455ed731b0d263fbe2bf79dddf89fb1a2bc66b Author: J. Bruce Fields Date: Sun Feb 28 16:33:31 2010 -0500 Revert "sunrpc: move the close processing after do recvfrom method" commit 1b644b6e6f6160ae35ce4b52c2ca89ed3e356e18 upstream. This reverts commit b0401d725334a94d57335790b8ac2404144748ee, which moved svc_delete_xprt() outside of XPT_BUSY, and allowed it to be called after svc_xpt_recived(), removing its last reference and destroying it after it had already been queued for future processing. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 9f6ce8f6c434473a319a1d8b552e6b6847fa5539 Author: J. Bruce Fields Date: Sun Feb 28 16:32:51 2010 -0500 Revert "sunrpc: fix peername failed on closed listener" commit f5822754ea006563e1bf0a1f43faaad49c0d8bb2 upstream. This reverts commit b292cf9ce70d221c3f04ff62db5ab13d9a249ca8. The commit that it attempted to patch up, b0401d725334a94d57335790b8ac2404144748ee, was fundamentally wrong, and will also be reverted. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 139b4a2e8bdefa6ab6849d1aaac9ea6d962592b7 Author: J. Bruce Fields Date: Tue Oct 20 18:51:34 2009 -0400 nfsd4: don't try to map gid's in generic rpc code commit dc83d6e27fa80babe31c80aa8568f125f72edf57 upstream. For nfsd we provide users the option of mapping uid's to server-side supplementary group lists. That makes sense for nfsd, but not necessarily for other rpc users (such as the callback client). So move that lookup to svcauth_unix_set_client, which is a program-specific method. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 31bbea0a639f04ed0047155f154c18afbc49259e Author: NeilBrown Date: Wed Mar 31 12:07:16 2010 +1100 md: deal with merge_bvec_fn in component devices better. commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 upstream. If a component device has a merge_bvec_fn then as we never call it we must ensure we never need to. Currently this is done by setting max_sector to 1 PAGE, however this does not stop a bio being created with several sub-page iovecs that would violate the merge_bvec_fn. So instead set max_phys_segments to 1 and set the segment boundary to the same as a page boundary to ensure there is only ever one single-page segment of IO requested at a time. This can particularly be an issue when 'xen' is used as it is known to submit multiple small buffers in a single bio. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit d150a2b96558a7349cbf3a72a279c37bc67d50fb Author: Mathieu Desnoyers Date: Tue Apr 20 10:38:10 2010 -0400 module: fix __module_ref_addr() The __module_ref_addr() problem disappears in 2.6.34-rc kernels because these percpu accesses were re-factored. __module_ref_addr() should use per_cpu_ptr() to obfuscate the pointer (RELOC_HIDE is needed for per cpu pointers). This non-standard per-cpu pointer use has been introduced by commit 720eba31f47aeade8ec130ca7f4353223c49170f It causes a NULL pointer exception on some configurations when CONFIG_TRACING is enabled on 2.6.33. This patch fixes the problem (acknowledged by Randy who reported the bug). It did not appear to hurt previously because most of the accesses were done through local_inc, which probably obfuscated the access enough that no compiler optimizations were done. But with local_read() done when CONFIG_TRACING is active, this becomes a problem. Non-CONFIG_TRACING is probably affected as well (module.c contains local_set and local_read that use __module_ref_addr()), but I guess nobody noticed because we've been lucky enough that the compiler did not generate the inappropriate optimization pattern there. This patch should be queued for the 2.6.29.x through 2.6.33.x stable branches. (tested on 2.6.33.1 x86_64) Signed-off-by: Mathieu Desnoyers Tested-by: Randy Dunlap CC: Eric Dumazet CC: Rusty Russell CC: Peter Zijlstra CC: Tejun Heo CC: Ingo Molnar CC: Andrew Morton CC: Linus Torvalds CC: Greg Kroah-Hartman CC: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b6b3dcd55e2327a968833ff3f22eda3b8dd7ef9e Author: Mathieu Desnoyers Date: Tue Apr 20 10:33:50 2010 -0400 lockdep: fix incorrect percpu usage The mainline kernel as of 2.6.34-rc5 is not affected by this problem because commit 10fad5e46f6c7bdfb01b1a012380a38e3c6ab346 fixed it by refactoring. lockdep fix incorrect percpu usage Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers). git blame points to commit: lockdep.c: commit 8e18257d29238311e82085152741f0c3aa18b74d But it's really just moving the code around. But it's enough to say that the problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23. It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these stable branches are still maintained). (tested on 2.6.33.1 x86_64) Signed-off-by: Mathieu Desnoyers CC: Randy Dunlap CC: Eric Dumazet CC: Rusty Russell CC: Peter Zijlstra CC: Tejun Heo CC: Ingo Molnar CC: Andrew Morton CC: Linus Torvalds CC: Greg Kroah-Hartman CC: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit ea0a09acd81c6d52c77d80f0d4089795df7bcb58 Author: Mathieu Desnoyers Date: Tue Apr 20 10:34:57 2010 -0400 modules: fix incorrect percpu usage Mainline does not need this fix, as commit 259354deaaf03d49a02dbb9975d6ec2a54675672 fixed the problem by refactoring. Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed for per cpu pointers). Introduced by commit: module.c: commit 6b588c18f8dacfa6d7957c33c5ff832096e752d3 This patch should be queued for the stable branch, for kernels 2.6.29.x to 2.6.33.x. (tested on 2.6.33.1 x86_64) Signed-off-by: Mathieu Desnoyers CC: Randy Dunlap CC: Eric Dumazet CC: Rusty Russell CC: Peter Zijlstra CC: Tejun Heo CC: Ingo Molnar CC: Andrew Morton CC: Linus Torvalds CC: Greg Kroah-Hartman CC: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 4186c4e6ebec12c705065b353c5fd7a1a87eea7d Author: Ping Cheng Date: Mon Apr 19 11:10:50 2010 -0700 Input: wacom - switch mode upon system resume commit 014f61504af276ba9d9544d8a7401d8f8526eb73 upstream. When Wacom devices wake up from a sleep, the switch mode command (wacom_query_tablet_data) is needed before wacom_open is called. wacom_query_tablet_data should not be executed inside wacom_open since wacom_open is called more than once during probe. Reported-and-tested-by: Anton Anikin Signed-off-by: Ping Cheng Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ea50da76fac43bf45365862110d3c19247411896 Author: Alexey Starikovskiy Date: Fri Apr 16 15:36:40 2010 -0400 ACPI: EC: Limit burst to 64 bits commit 2060c44576c79086ff24718878d7edaa7384a985 upstream. access_bit_width field is u8 in ACPICA, thus 256 value written to it becomes 0, causing divide by zero later. Proper fix would be to remove access_bit_width at all, just because we already have access_byte_width, which is access_bit_width / 8. Limit access width to 64 bit for now. https://bugzilla.kernel.org/show_bug.cgi?id=15749 fixes regression caused by the fix for: https://bugzilla.kernel.org/show_bug.cgi?id=14667 Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit a7fcc269cf6c6a531067a62716a661f4482d726a Author: Alexey Starikovskiy Date: Sat Apr 10 02:18:35 2010 +0100 ACPI: EC: Allow multibyte access to EC commit dadf28a10c3eb29421837a2e413ab869ebd upstream http://bugzilla.kernel.org/show_bug.cgi?id=14667 [bwh: Backport to 2.6.32; same applies to 2.6.33] Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit c68bfeb5ca8332bd08d086a983e87167e970643d Author: Peter Zijlstra Date: Fri Apr 16 05:14:41 2010 -0400 perf_events, x86: Implement Intel Westmere/Nehalem-EX support original patch commit ids: 452a339a976e7f782c786eb3f73080401e2fa3a6 and 134fbadf028a5977a1b06b0253d3ee33e6f0c642 perf_events, x86: Implement Intel Westmere support The new Intel documentation includes Westmere arch specific event maps that are significantly different from the Nehalem ones. Add support for this generation. Found the CPUID model numbers on wikipedia. Also ammend some Nehalem constraints, spotted those when looking for the differences between Nehalem and Westmere. Signed-off-by: Peter Zijlstra Cc: Arjan van de Ven Cc: "H. Peter Anvin" Cc: Stephane Eranian LKML-Reference: <20100127221122.151865645@chello.nl> Signed-off-by: Ingo Molnar perf, x86: Enable Nehalem-EX support According to Intel Software Devel Manual Volume 3B, the Nehalem-EX PMU is just like regular Nehalem (except for the uncore support, which is completely different). Signed-off-by: Vince Weaver Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: "H. Peter Anvin" Cc: Arjan van de Ven Cc: Lin Ming LKML-Reference: Signed-off-by: Ingo Molnar Cc: Youquan Song commit 06c87c1c38ff842c251e253a2040664885a2c104 Author: Damian Lukowski Date: Wed Feb 10 18:04:08 2010 -0800 tcp: fix ICMP-RTO war commit 598856407d4e20ebb4de01a91a93d89325924d43 upstream. Make sure, that TCP has a nonzero RTT estimation after three-way handshake. Currently, a listening TCP has a value of 0 for srtt, rttvar and rto right after the three-way handshake is completed with TCP timestamps disabled. This will lead to corrupt RTO recalculation and retransmission flood when RTO is recalculated on backoff reversion as introduced in "Revert RTO on ICMP destination unreachable" (f1ecd5d9e7366609d640ff4040304ea197fbc618). This behaviour can be provoked by connecting to a server which "responds first" (like SMTP) and rejecting every packet after the handshake with dest-unreachable, which will lead to softirq load on the server (up to 30% per socket in some tests). Thanks to Ilpo Jarvinen for providing debug patches and to Denys Fedoryshchenko for reporting and testing. Changes since v3: Removed bad characters in patchfile. Reported-by: Denys Fedoryshchenko Signed-off-by: Damian Lukowski Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 899854b6266b24ed162e363f86006c24e82b2885 Author: Neil Horman Date: Mon Mar 29 13:16:02 2010 -0700 r8169: offical fix for CVE-2009-4537 (overlength frame DMAs) commit c0cd884af045338476b8e69a61fceb3f34ff22f1 upstream. Official patch to fix the r8169 frame length check error. Based on this initial thread: http://marc.info/?l=linux-netdev&m=126202972828626&w=1 This is the official patch to fix the frame length problems in the r8169 driver. As noted in the previous thread, while this patch incurs a performance hit on the driver, its possible to improve performance dynamically by updating the mtu and rx_copybreak values at runtime to return performance to what it was for those NICS which are unaffected by the ideosyncracy (if there are any). Summary: A while back Eric submitted a patch for r8169 in which the proper allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too much data. This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4. A long time prior to that however, Francois posted 126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize setting due to the fact that the hardware behaved in odd ways when overlong frames were received on NIC's supported by this driver. This was mentioned in a security conference recently: http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html It seems that if we can't enable frame size filtering, then, as Eric correctly noticed, we can find ourselves DMA-ing too much data to a buffer, causing corruption. As a result is seems that we are forced to allocate a frame which is ready to handle a maximally sized receive. This obviously has performance issues with it, so to mitigate that issue, this patch does two things: 1) Raises the copybreak value to the frame allocation size, which should force appropriately sized packets to get allocated on rx, rather than a full new 16k buffer. 2) This patch only disables frame filtering initially (i.e., during the NIC open), changing the MTU results in ring buffer allocation of a size in relation to the new mtu (along with a warning indicating that this is dangerous). Because of item (2), individuals who can't cope with the performance hit (or can otherwise filter frames to prevent the bug), or who have hardware they are sure is unaffected by this issue, can manually lower the copybreak and reset the mtu such that performance is restored easily. Signed-off-by: Neil Horman Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 87ef9895abd28755732e599070d1ede1a1f90c27 Author: Terry Loftin Date: Fri Apr 9 10:29:49 2010 +0000 e1000e: stop cleaning when we reach tx_ring->next_to_use commit dac876193cd79ced36d0462749ea47c05844fb49 upstream. Tx ring buffers after tx_ring->next_to_use are volatile and could change, possibly causing a crash. Stop cleaning when we hit tx_ring->next_to_use. Signed-off-by: Terry Loftin Acked-by: Bruce Allan Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Cc: Matthew Burgess Signed-off-by: Greg Kroah-Hartman commit bbcb1d90f0b20e097ff6e2f80b130a92c73dde7d Author: Reinette Chatre Date: Tue Feb 2 10:57:12 2010 -0800 iwlwifi: fix scan race commit bbcbb9ef9735c67da303d30bd6beb9e699f0f508 upstream. There is a problem if an "internal short scan" is in progress when a mac80211 requested scan arrives. If this new scan request arrives within the "next_scan_jiffies" period then driver will immediately return success and complete the scan. The problem here is that the scan has not been fully initialized at this time (is_internal_short_scan is still set to true because of the currently running scan), which results in the scan completion never to be sent to mac80211. At this time also, evan though the internal short scan is still running the state (is_internal_short_scan) will be set to false, so when the internal scan does complete then mac80211 will receive a scan completion. Fix this by checking right away if a scan is in progress when a scan request arrives from mac80211. Signed-off-by: Reinette Chatre Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit f772fcf6054544c4dd9694e1037cad50bd850a53 Author: Wey-Yi Guy Date: Tue Feb 2 16:58:34 2010 -0800 iwlwifi: clear all tx queues when firmware ready commit dff010ac8e57e43669518a14c0e945dfeb80c2a7 upstream. Reset and clear all the tx queues when finished downloading runtime uCode and ready to go into operation mode. Signed-off-by: Wey-Yi Guy Signed-off-by: Reinette Chatre Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit f48673e5235732da41d9cd57365a5a3d7b71a32e Author: Oliver Neukum Date: Wed Mar 3 00:37:56 2010 +0100 USB: cdc-acm: Fix stupid NULL pointer in resume() commit f0730924e9e32bb8935c60040a26d94179355088 upstream. Stupid logic bug passing a just nulled pointer Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9db126bccc557e0587740094e3c2c7d3451c5de9 Author: Oliver Neukum Date: Wed Dec 16 17:05:57 2009 +0100 USB: cdc-acm: Update to new autopm API commit 97d35f95552c9a0ee4777a7f04431a9fd1260478 upstream. Update cdc-acm to the async methods eliminating the workqueue [This fixes a reported lockup for the cdc-acm driver - gregkh] Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit c6fc81afa2d7ef2f775e48672693d8a0a8a7325d Author: John Wright Date: Tue Apr 13 16:55:37 2010 -0600 sched: Fix a race between ttwu() and migrate_task() Based on commit e2912009fb7b715728311b0d8fe327a1432b3f79 upstream, but done differently as this issue is not present in .33 or .34 kernels due to rework in this area. If a task is in the TASK_WAITING state, then try_to_wake_up() is working on it, and it will place it on the correct cpu. This commit ensures that neither migrate_task() nor __migrate_task() calls set_task_cpu(p) while p is in the TASK_WAKING state. Otherwise, there could be two concurrent calls to set_task_cpu(p), resulting in the task's cfs_rq being inconsistent with its cpu. Signed-off-by: John Wright Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 328851d3f993704cb61a74cdf8af88d987302812 Author: Christian Pulvermacher Date: Tue Mar 23 11:51:38 2010 -0500 ecryptfs: fix error code for missing xattrs in lower fs commit cfce08c6bdfb20ade979284e55001ca1f100ed51 upstream. If the lower file system driver has extended attributes disabled, ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP. This breaks execution of programs in the ecryptfs mount, since the kernel expects the latter error when checking for security capabilities in xattrs. Signed-off-by: Christian Pulvermacher Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 0bee0a7baf562b6094b1da266c46ec0acec5d7e6 Author: Tyler Hicks Date: Mon Mar 22 00:41:35 2010 -0500 eCryptfs: Decrypt symlink target for stat size commit 3a60a1686f0d51c99bd0df8ac93050fb6dfce647 upstream. Create a getattr handler for eCryptfs symlinks that is capable of reading the lower target and decrypting its path. Prior to this patch, a stat's st_size field would represent the strlen of the encrypted path, while readlink() would return the strlen of the decrypted path. This could lead to confusion in some userspace applications, since the two values should be equal. https://bugs.launchpad.net/bugs/524919 Reported-by: Loïc Minier Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit c1fd3a9cbe9d26e14c1fb2c820c906fdc6b068a0 Author: Jeff Mahoney Date: Fri Mar 19 15:35:46 2010 -0400 ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode commit 133b8f9d632cc23715c6d72d1c5ac449e054a12a upstream. Since tmpfs has no persistent storage, it pins all its dentries in memory so they have d_count=1 when other file systems would have d_count=0. ->lookup is only used to create new dentries. If the caller doesn't instantiate it, it's freed immediately at dput(). ->readdir reads directly from the dcache and depends on the dentries being hashed. When an ecryptfs mount is mounted, it associates the lower file and dentry with the ecryptfs files as they're accessed. When it's umounted and destroys all the in-memory ecryptfs inodes, it fput's the lower_files and d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in 2008 and several months later commit caeeeecf removed the d_delete. I believe the d_drop() needs to be removed as well. The d_drop effectively hides any file that has been accessed via ecryptfs from the underlying tmpfs since it depends on it being hashed for it to be accessible. I've removed the d_drop on my development node and see no ill effects with basic testing on both tmpfs and persistent storage. As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs BUGs on umount. This is due to the dentries being unhashed. tmpfs->kill_sb is kill_litter_super which calls d_genocide to drop the reference pinning the dentry. It skips unhashed and negative dentries, but shrink_dcache_for_umount_subtree doesn't. Since those dentries still have an elevated d_count, we get a BUG(). This patch removes the d_drop call and fixes both issues. This issue was reported at: https://bugzilla.novell.com/show_bug.cgi?id=567887 Reported-by: Árpád Bíró Signed-off-by: Jeff Mahoney Cc: Dustin Kirkland Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit b8798e6f8ed0dca2cc5c0e3f65a3c14261b7052b Author: Michael Buesch Date: Fri Oct 9 20:33:32 2009 +0200 b43: Optimize PIO scratchbuffer usage commit 88499ab3d8dbbf9c080416952603742666c71262 upstream. This optimizes the PIO scratchbuffer usage. Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8bb98f7cae996013a2cf1ccd4bc375b8189b52e9 Author: Bjorn Helgaas Date: Thu Jan 7 12:58:51 2010 -0700 agp/hp: fixup hp agp after ACPI changes commit 67fe63b0715ccfaefa0af8a6e705c5470ee5cada upstream. Commit 15b8dd53f5ffa changed the string in info->hardware_id from a static array to a pointer and added a length field. But instead of changing "sizeof(array)" to "length", we changed it to "sizeof(length)" (== 4), which corrupts the string we're trying to null-terminate. We no longer even need to null-terminate the string, but we *do* need to check whether we found a HID. If there's no HID, we used to have an empty array, but now we have a null pointer. The combination of these defects causes this oops: Unable to handle kernel NULL pointer dereference (address 0000000000000003) modprobe[895]: Oops 8804682956800 [1] ip is at zx1_gart_probe+0xd0/0xcc0 [hp_agp] http://marc.info/?l=linux-ia64&m=126264484923647&w=2 Signed-off-by: Bjorn Helgaas Reported-by: Émeric Maschino Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit fca6a735cc3b070a25c3fa2b09073ff836307d24 Author: Takashi Iwai Date: Thu Apr 15 09:02:41 2010 +0200 ALSA: hda - Add position_fix quirk for Biostar mobo commit 8815cd030fdd73932a791d1f06194c8db807cde7 upstream. The Biostar mobo seems to give a wrong DMA position, resulting in stuttering or skipping sounds on 2.6.34. Since the commit 7b3a177b0d4f92b3431b8dca777313a07533a710, "ALSA: pcm_lib: fix "something must be really wrong" condition", makes the position check more strictly, the DMA position problem is revealed more clearly now. The fix is to use only LPIB for obtaining the position, i.e. passing position_fix=1. This patch adds a static quirk to achieve it as default. Reported-by: Frank Griffin Cc: Eric Piel Signed-off-by: Takashi Iwai Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 04f6e0977f1180ebb2a34169aca8f83bb0154caf Author: Linus Torvalds Date: Fri Feb 26 10:34:27 2010 -0800 b43: fall back gracefully to PIO mode after fatal DMA errors commit 9e3bd9190800e8209b4a3e1d724c35f0738dcad2 upstream. This makes the b43 driver just automatically fall back to PIO mode when DMA doesn't work. The driver already told the user to do it, so rather than have the user reload the module with a new flag, just make the driver do it automatically. We keep the message as an indication that something is wrong, but now just automatically fall back to the hopefully working PIO case. (Some post-2.6.33 merge fixups by Larry Finger and yours truly... -- JWL) Signed-off-by: Linus Torvalds Signed-off-by: John W. Linville Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 2e53415d0c9daa3bd7a6996727f311ca30b0f552 Author: Larry Finger Date: Thu Dec 10 17:35:01 2009 -0600 b43: Allow PIO mode to be selected at module load commit b02914af4d7020828ce921a572589dd793517c09 upstream. If userencounter the "Fatal DMA Problem" with a BCM43XX device, and still wish to use b43 as the driver, their only option is to rebuild the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and allows PIO mode to be selected with a load-time parameter for the module. Note that the configuration variable CONFIG_B43_PIO is also removed. Once the DMA problem with the BCM4312 devices is solved, this patch will likely be reverted. Signed-off-by: Larry Finger Tested-by: John Daiker Cc: maximilian attems Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a56d040407bfbb67c0c3c15994768ed389d2b93f Author: Larry Finger Date: Wed Dec 9 13:25:56 2009 -0600 b43: Remove reset after fatal DMA error commit 214ac9a4ead6cb254451c09d9c8234a76693feb1 upstream. As shown in Kernel Bugzilla #14761, doing a controller restart after a fatal DMA error does not accomplish anything other than consume the CPU on an affected system. Accordingly, substitute a meaningful message for the restart. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit c10fdc2140e1c4de6bde59b1802f7e914d81b38d Author: Seth Heasley Date: Tue Mar 2 12:23:39 2010 +0100 i2c-i801: Add Intel Cougar Point device IDs commit 393764340beb595c1ad7dd2d2243c2b6551aaa71 upstream. Add the Intel Cougar Point (PCH) SMBus controller device IDs. Signed-off-by: Seth Heasley Signed-off-by: Jean Delvare Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 2e1efde6b0f7a4ff09c6f41d33545b66022ae297 Author: Seth Heasley Date: Tue Jan 12 17:00:18 2010 -0800 ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDs commit 5623cab83ea61e0420f2064216d83eab067a24c6 upstream. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 3c1bd2b856ddd2dde17076468de1933f78bd2ef7 Author: Seth Heasley Date: Tue Jan 12 17:01:28 2010 -0800 ata_piix: IDE Mode SATA patch for Intel Cougar Point DeviceIDs commit 88e8201e67aace3d86de9e75122ea525f0e7248e upstream. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit d5771ad1cc4cab9c48e481903501f5297e67a5a1 Author: Seth Heasley Date: Mon Feb 22 17:31:09 2010 -0800 ALSA: hda - enable snoop for Intel Cougar Point commit 32679f95cac3b1bdf27dce8b5273e06af186fd91 upstream. This patch enables snoop, eliminating static during playback. This patch supersedes the previous Cougar Point audio patch. Signed-off-by: Seth Heasley Signed-off-by: Takashi Iwai Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 397e6f81f0e3cdc9ee0a6a28c55530e937b6aa45 Author: Seth Heasley Date: Tue Jan 12 17:03:35 2010 -0800 ALSA: hda_intel: ALSA HD Audio patch for Intel Cougar Point DeviceIDs commit d2f2fcd2541bae004db7f4798ffd9d2cb75ae817 upstream. This patch adds the Intel Cougar Point (PCH) HD Audio Controller DeviceIDs. Signed-off-by: Seth Heasley Signed-off-by: Takashi Iwai Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 9a9e24c8c13cb61e22ddc201a64f173671f2df9d Author: Seth Heasley Date: Tue Jan 12 16:56:37 2010 -0800 x86/PCI: irq and pci_ids patch for Intel Cougar Point DeviceIDs commit 93da6202264ce1256b04db8008a43882ae62d060 upstream. This patch adds the Intel Cougar Point (PCH) LPC and SMBus Controller DeviceIDs. Signed-off-by: Seth Heasley Signed-off-by: Jesse Barnes Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 098f33f949f58aa7ad969a90ef0c573626bad6ac Author: Eli Cohen Date: Wed Mar 3 12:27:52 2010 +0000 IPoIB: Fix TX queue lockup with mixed UD/CM traffic commit f0dc117abdfa9a0e96c3d013d836460ef3cd08c7 upstream. The IPoIB UD QP reports send completions to priv->send_cq, which is usually left unarmed; it only gets armed when the number of outstanding send requests reaches the size of the TX queue. This arming is done only in the send path for the UD QP. However, when sending CM packets, the net queue may be stopped for the same reasons but no measures are taken to recover the UD path from a lockup. Consider this scenario: a host sends high rate of both CM and UD packets, with a TX queue length of N. If at some time the number of outstanding UD packets is more than N/2 and the overall outstanding packets is N-1, and CM sends a packet (making the number of outstanding sends equal N), the TX queue will be stopped. When all the CM packets complete, the number of outstanding packets will still be higher than N/2 so the TX queue will not be restarted. Fix this by calling ib_req_notify_cq() when the queue is stopped in the CM path. Signed-off-by: Eli Cohen Signed-off-by: Roland Dreier Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 90022a26dd2e166ae1ac3953d266ea42f083d65e Author: Andrew Patterson Date: Fri Jan 22 14:06:53 2010 -0700 PCI: fix nested spinlock hang in aer_inject commit bd1f46deba615971a58193afd0202878cadf19a7 upstream. The aer_inject module hangs in aer_inject() when checking the device's error masks. The hang is due to a recursive use of the aer_inject lock. The aer_inject() routine grabs the lock while processing the error and then calls pci_read_config_dword to read the masks. The pci_read_config_dword routine is earlier overridden by pci_read_aer, which among other things, grabs the aer_inject lock. Fixed by moving the pci_read_config_dword calls to read the masks to before the lock is taken. Acked-by: Huang Ying Signed-off-by: Andrew Patterson Signed-off-by: Jesse Barnes Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 892cb6dc64b73037b756fd1b0014e8c2280ae28d Author: Paul Mundt Date: Thu Mar 11 14:08:33 2010 -0800 PCI: kill off pci_register_set_vga_state() symbol export. commit ded1d8f29b4d315a2093cafc3ee17ac870a87972 upstream. When pci_register_set_vga_state() was made __init, the EXPORT_SYMBOL() was retained, which now leaves us with a section mismatch. Signed-off-by: Paul Mundt Cc: Mike Travis Signed-off-by: Andrew Morton Signed-off-by: Jesse Barnes Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit a6f2691c29ef956de68ed070f0a74a7a22e24fd6 Author: Mike Travis Date: Tue Feb 2 14:38:13 2010 -0800 pci: Update pci_set_vga_state() to call arch functions commit 95a8b6efc5d07103583f706c8a5889437d537939 upstream. Update pci_set_vga_state to call arch dependent functions to enable Legacy VGA I/O transactions to be redirected to correct target. [akpm@linux-foundation.org: make pci_register_set_vga_state() __init] Signed-off-by: Mike Travis LKML-Reference: <201002022238.o12McE1J018723@imap1.linux-foundation.org> Cc: Thomas Gleixner Cc: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Cc: Jesse Barnes Cc: David Airlie Signed-off-by: Andrew Morton Signed-off-by: H. Peter Anvin Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit cf1b641450854a784a388273b089181c34a00b6c Author: Harish Zunjarrao Date: Tue Jan 12 12:59:50 2010 -0800 SCSI: fc-transport: Use packed modifier for fc_bsg_request structure. commit eda05a28ec52be40086400a1b606d211276f0e41 upstream. The 32bit kernel does not add padding bytes in the fc_bsg_request structure whereas the 64bit kernel adds padding bytes in the fc_bsg_request structure. Due to this, structure elements gets mismatched with 32bit application and 64bit kernel.To resolve this, used packed modifier to avoid adding padding bytes. Signed-off-by: Giridhar Malavali Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 7de7b92d392d6c82587085b03f6cdfecccccb61d Author: Mike Travis Date: Tue Feb 2 14:38:15 2010 -0800 vgaarb: Fix VGA arbiter to accept PCI domains other than 0 commit 773a38dbdad03474c5ee235f7d9bf9f51c9e3c2b upstream. Update the VGA Arbiter to accept PCI Domains other than 0. Signed-off-by: Mike Travis LKML-Reference: <201002022238.o12McFe8018730@imap1.linux-foundation.org> Cc: Thomas Gleixner Cc: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Cc: Jesse Barnes Cc: David Airlie Signed-off-by: Andrew Morton Signed-off-by: H. Peter Anvin Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 9623f6b42a74645cbf05432a57d19363bc072bb2 Author: Youquan Song Date: Thu Dec 17 08:22:48 2009 -0500 PCIe AER: prevent AER injection if hardware masks error reporting commit b49bfd32901625e4adcfee011d2b32a43b4db67d upstream. The Correcteable/Uncorrectable Error Mask Registers are used by PCIe AER driver which will controls the reporting of individual errors to PCIe RC via PCIe error messages. If hardware masks special error reporting to RC, the aer_inject driver should not inject aer error. Acked-by: Andi Kleen Signed-off-by: Youquan Song Acked-by: Ying Huang Signed-off-by: Jesse Barnes Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit a8fa34c446b119c68cb88c5a787aa7055a33f949 Author: Alexander Duyck Date: Mon Oct 5 06:33:27 2009 +0000 igb: add support for 82576NS SerDes adapter commit 747d49baaf4e3f4ad5ae77477830da026eeef69d upstream. This patch adds the device ID necessary to support the 82576NS SerDes adapter. Signed-off-by: Alexander Duyck Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit f435966fc52949d46680c8f953ae7a27e5b5c564 Author: Mike Christie Date: Thu Nov 5 11:37:28 2009 -0600 SCSI: add scsi target reset support to scsi ioctl commit 3f9daedfcb197d784c6e7ecd731e3aa9859bc951 upstream. The scsi ioctl code path was missing scsi target reset support. This patch just adds it. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 285f4f1123e1c977eb5dfa7704cc6356be079581 Author: Mike Christie Date: Thu Nov 5 11:18:09 2009 -0600 fc class: fail fast bsg requests commit 2bc1c59dbdefdb6f9767e06efb86bbdb2923a8be upstream. If the port state is blocked and the fast io fail tmo has fired then this patch will fail bsg requests immediately. This is needed if userspace is sending IOs to test the transport like with fcping, so it will not have to wait for the dev loss tmo. With this patch he bsg req fast io fail code behaves like the normal and sg io/passthrough fast io fail. Signed-off-by: Mike Christie Acked-By: James Smart Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 56d704107153877ba124c9fafb31fb54a86a0f84 Author: Sachin Prabhu Date: Sat Mar 13 09:03:55 2010 -0600 9p: Skip check for mandatory locks when unlocking commit f78233dd44a110c574fe760ad6f9c1e8741a0d00 upstream. While investigating a bug, I came across a possible bug in v9fs. The problem is similar to the one reported for NFS by ASANO Masahiro in http://lkml.org/lkml/2005/12/21/334. v9fs_file_lock() will skip locks on file which has mode set to 02666. This is a problem in cases where the mode of the file is changed after a process has obtained a lock on the file. Such a lock will be skipped during unlock and the machine will end up with a BUG in locks_remove_flock(). v9fs_file_lock() should skip the check for mandatory locks when unlocking a file. Signed-off-by: Sachin Prabhu Signed-off-by: Eric Van Hensbergen Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 26ec941a150774814a0416b28c7e8d22bfb777f8 Author: Tao Ma Date: Wed Mar 3 11:26:27 2010 +0800 ocfs2: Change bg_chain check for ocfs2_validate_gd_parent. commit 78c37eb0d5e6a9727b12ea0f1821795ffaa66cfe upstream. In ocfs2_validate_gd_parent, we check bg_chain against the cl_next_free_rec of the dinode. Actually in resize, we have the chance of bg_chain == cl_next_free_rec. So add some additional condition check for it. I also rename paramter "clean_error" to "resize", since the old one is not clearly enough to indicate that we should only meet with this case in resize. btw, the correpsonding bug is http://oss.oracle.com/bugzilla/show_bug.cgi?id=1230. Signed-off-by: Tao Ma Signed-off-by: Joel Becker Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 80acb6490eca937a70e00e69fcae35f92ea0ad63 Author: Mark Fasheh Date: Mon Mar 15 15:39:00 2010 -0700 ocfs2: set i_mode on disk during acl operations commit fcefd25ac89239cb57fa198f125a79ff85468c75 upstream. ocfs2_set_acl() and ocfs2_init_acl() were setting i_mode on the in-memory inode, but never setting it on the disk copy. Thus, acls were some times not getting propagated between nodes. This patch fixes the issue by adding a helper function ocfs2_acl_set_mode() which does this the right way. ocfs2_set_acl() and ocfs2_init_acl() are then updated to call ocfs2_acl_set_mode(). Signed-off-by: Mark Fasheh Signed-off-by: Joel Becker Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 361096052132966bc6a25b0826d59c2c3babc244 Author: Bernd Porr Date: Fri Nov 27 12:00:53 2009 +0000 Staging: comedi: usbdux.c: fix locking up of the driver when the comedi ringbuffer runs empty commit d4c3a56587af3edbe5f618b20e800e9f9fde13cb upstream. Jan-Matthias Braun spotted a bug which locks up the driver when the comedi ring buffer runs empty and provided a patch. The driver would still send the data to comedi but the reader won't wake up any more. What's required is setting the flag COMEDI_CB_BLOCK after new data has arrived which wakes up the reader and therefore the read() command. Signed-off-by: Bernd Porr Signed-off-by: Leann Ogasawara Signed-off-by: Greg Kroah-Hartman commit 3410f6e8e3a96baf279946e454ed70a8e43fb448 Author: Bernd Porr Date: Mon Nov 16 01:12:02 2009 +0000 Staging: comedi: fix usbdux timeout bug commit ea25371a78c33e276527361d3ab19393d558b2fd upstream. I've fixed a bug in the USBDUX driver which caused timeouts while sending commands to the boards. This was mainly because of one bulk transfer which had a timeout of 1ms (!). I've now set all timeouts to 1000ms. From: Bernd Porr Signed-off-by: Leann Ogasawara Signed-off-by: Greg Kroah-Hartman commit b297f8be79425ac8cadad84908e7088a434f39fa Author: Andrew Perepechko Date: Mon Apr 12 22:16:50 2010 +0400 quota: Fix possible dq_flags corruption commit 08261673cb6dc638c39f44d69b76fffb57b92a8b upstream. dq_flags are modified non-atomically in do_set_dqblk via __set_bit calls and atomically for example in mark_dquot_dirty or clear_dquot_dirty. Hence a change done by an atomic operation can be overwritten by a change done by a non-atomic one. Fix the problem by using atomic bitops even in do_set_dqblk. Signed-off-by: Andrew Perepechko Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 2548bd8d60f4c689d908adac6f805878b7eda904 Author: Kiyoshi Ueda Date: Fri Mar 26 12:03:13 2010 +0530 dm mpath: fix stall when requeueing io upstream commit 9eef87da2a8ea4920e0d913ff977cac064b68ee0 backported to 2.6.32.10 by Nikanth Karthikesan This patch fixes the problem that system may stall if target's ->map_rq returns DM_MAPIO_REQUEUE in map_request(). E.g. stall happens on 1 CPU box when a dm-mpath device with queue_if_no_path bounces between all-paths-down and paths-up on I/O load. When target's ->map_rq returns DM_MAPIO_REQUEUE, map_request() requeues the request and returns to dm_request_fn(). Then, dm_request_fn() doesn't exit the I/O dispatching loop and continues processing the requeued request again. This map and requeue loop can be done with interrupt disabled, so 1 CPU system can be stalled if this situation happens. For example, commands below can stall my 1 CPU box within 1 minute or so: # dmsetup table mp mp: 0 2097152 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 2 8:144 1 1 # while true; do dd if=/dev/mapper/mp of=/dev/null bs=1M count=100; done & # while true; do \ > dmsetup message mp 0 "fail_path 8:144" \ > dmsetup suspend --noflush mp \ > dmsetup resume mp \ > dmsetup message mp 0 "reinstate_path 8:144" \ > done To fix the problem above, this patch changes dm_request_fn() to exit the I/O dispatching loop once if a request is requeued in map_request(). Signed-off-by: Kiyoshi Ueda Signed-off-by: Jun'ichi Nomura Signed-off-by: Alasdair G Kergon Signed-off-by: Nikanth Karthikesan Signed-off-by: Greg Kroah-Hartman commit 839f573c0438d44d1df1df96963150668d5846c9 Author: Al Viro Date: Sat Jan 30 16:11:21 2010 -0500 fix NFS4 handling of mountpoint stat commit 462d60577a997aa87c935ae4521bd303733a9f2b upstream. RFC says we need to follow the chain of mounts if there's more than one stacked on that point. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e422a4a5d60c8dbef19df3ea16aaf7556cd26223 Author: Avi Kivity Date: Sat Feb 13 10:33:12 2010 +0200 x86-64, rwsem: Avoid store forwarding hazard in __downgrade_write commit 0d1622d7f526311d87d7da2ee7dd14b73e45d3fc upstream. The Intel Architecture Optimization Reference Manual states that a short load that follows a long store to the same object will suffer a store forwading penalty, particularly if the two accesses use different addresses. Trivially, a long load that follows a short store will also suffer a penalty. __downgrade_write() in rwsem incurs both penalties: the increment operation will not be able to reuse a recently-loaded rwsem value, and its result will not be reused by any recently-following rwsem operation. A comment in the code states that this is because 64-bit immediates are special and expensive; but while they are slightly special (only a single instruction allows them), they aren't expensive: a test shows that two loops, one loading a 32-bit immediate and one loading a 64-bit immediate, both take 1.5 cycles per iteration. Fix this by changing __downgrade_write to use the same add instruction on i386 and on x86_64, so that it uses the same operand size as all the other rwsem functions. Signed-off-by: Avi Kivity LKML-Reference: <1266049992-17419-1-git-send-email-avi@redhat.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit f9a05e26cad0db0dd9299bb43443319e79a6de7e Author: Linus Torvalds Date: Sun Jan 17 10:24:07 2010 -0800 x86: Fix breakage of UML from the changes in the rwsem system commit 4126faf0ab7417fbc6eb99fb0fd407e01e9e9dfe upstream. The patches 5d0b7235d83eefdafda300656e97d368afcafc9a and bafaecd11df15ad5b1e598adc7736afcd38ee13d broke the UML build: On Sun, 17 Jan 2010, Ingo Molnar wrote: > > FYI, -tip testing found that these changes break the UML build: > > kernel/built-in.o: In function `__up_read': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:192: undefined reference to `call_rwsem_wake' > kernel/built-in.o: In function `__up_write': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:210: undefined reference to `call_rwsem_wake' > kernel/built-in.o: In function `__downgrade_write': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:228: undefined reference to `call_rwsem_downgrade_wake' > kernel/built-in.o: In function `__down_read': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:112: undefined reference to `call_rwsem_down_read_failed' > kernel/built-in.o: In function `__down_write_nested': > /home/mingo/tip/arch/x86/include/asm/rwsem.h:154: undefined reference to `call_rwsem_down_write_failed' > collect2: ld returned 1 exit status Add lib/rwsem_64.o to the UML subarch objects to fix. LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 70cc92a7f8ae8bed3fd73816045446a4403f4cef Author: Linus Torvalds Date: Tue Jan 12 18:16:42 2010 -0800 x86-64: support native xadd rwsem implementation commit bafaecd11df15ad5b1e598adc7736afcd38ee13d upstream. This one is much faster than the spinlock based fallback rwsem code, with certain artifical benchmarks having shown 300%+ improvement on threaded page faults etc. Again, note the 32767-thread limit here. So this really does need that whole "make rwsem_count_t be 64-bit and fix the BIAS values to match" extension on top of it, but that is conceptually a totally independent issue. NOT TESTED! The original patch that this all was based on were tested by KAMEZAWA Hiroyuki, but maybe I screwed up something when I created the cleaned-up series, so caveat emptor.. Also note that it _may_ be a good idea to mark some more registers clobbered on x86-64 in the inline asms instead of saving/restoring them. They are inline functions, but they are only used in places where there are not a lot of live registers _anyway_, so doing for example the clobbers of %r8-%r11 in the asm wouldn't make the fast-path code any worse, and would make the slow-path code smaller. (Not that the slow-path really matters to that degree. Saving a few unnecessary registers is the _least_ of our problems when we hit the slow path. The instruction/cycle counting really only matters in the fast path). Signed-off-by: Linus Torvalds LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 70701527e01ba5d3e5d5bc06736d6d9b2fbc1976 Author: H. Peter Anvin Date: Mon Jan 18 14:00:34 2010 -0800 x86-64, rwsem: 64-bit xadd rwsem implementation commit 1838ef1d782f7527e6defe87e180598622d2d071 upstream. For x86-64, 32767 threads really is not enough. Change rwsem_count_t to a signed long, so that it is 64 bits on x86-64. This required the following changes to the assembly code: a) %z0 doesn't work on all versions of gcc! At least gcc 4.4.2 as shipped with Fedora 12 emits "ll" not "q" for 64 bits, even for integer operands. Newer gccs apparently do this correctly, but avoid this problem by using the _ASM_ macros instead of %z. b) 64 bits immediates are only allowed in "movq $imm,%reg" constructs... no others. Change some of the constraints to "e", and fix the one case where we would have had to use an invalid immediate -- in that case, we only care about the upper half anyway, so just access the upper half. Signed-off-by: H. Peter Anvin Cc: Linus Torvalds LKML-Reference: Signed-off-by: Greg Kroah-Hartman commit e835682063e42068304c91e9143268ee0d444ee3 Author: Linus Torvalds Date: Tue Jan 12 17:57:35 2010 -0800 x86: clean up rwsem type system commit 5d0b7235d83eefdafda300656e97d368afcafc9a upstream. The fast version of the rwsems (the code that uses xadd) has traditionally only worked on x86-32, and as a result it mixes different kinds of types wildly - they just all happen to be 32-bit. We have "long", we have "__s32", and we have "int". To make it work on x86-64, the types suddenly matter a lot more. It can be either a 32-bit or 64-bit signed type, and both work (with the caveat that a 32-bit counter will only have 15 bits of effective write counters, so it's limited to 32767 users). But whatever type you choose, it needs to be used consistently. This makes a new 'rwsem_counter_t', that is a 32-bit signed type. For a 64-bit type, you'd need to also update the BIAS values. Signed-off-by: Linus Torvalds LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit e0c312c95bb3372d5f60442764b8431847c4f1af Author: Linus Torvalds Date: Tue Jan 12 16:21:09 2010 -0800 x86-32: clean up rwsem inline asm statements commit 59c33fa7791e9948ba467c2b83e307a0d087ab49 upstream. This makes gcc use the right register names and instruction operand sizes automatically for the rwsem inline asm statements. So instead of using "(%%eax)" to specify the memory address that is the semaphore, we use "(%1)" or similar. And instead of forcing the operation to always be 32-bit, we use "%z0", taking the size from the actual semaphore data structure itself. This doesn't actually matter on x86-32, but if we want to use the same inline asm for x86-64, we'll need to have the compiler generate the proper 64-bit names for the registers (%rax instead of %eax), and if we want to use a 64-bit counter too (in order to avoid the 15-bit limit on the write counter that limits concurrent users to 32767 threads), we'll need to be able to generate instructions with "q" accesses rather than "l". Since this header currently isn't enabled on x86-64, none of that matters, but we do want to use the xadd version of the semaphores rather than have to take spinlocks to do a rwsem. The mm->mmap_sem can be heavily contended when you have lots of threads all taking page faults, and the fallback rwsem code that uses a spinlock performs abysmally badly in that case. [ hpa: modified the patch to skip size suffixes entirely when they are redundant due to register operands. ] Signed-off-by: Linus Torvalds LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 7a3a3bba93b8d3bb93677838bfe2c1a03e686e72 Author: Eugene Teo Date: Tue Mar 23 10:52:13 2010 +0800 vgaarb: fix "target=default" passing Commit 77c1ff3982c6b36961725dd19e872a1c07df7f3b fixed the userspace pointer dereference, but introduced another bug pointed out by Eugene Teo in RH bug #564264. Instead of comparing the point we were at in the string, we instead compared the beginning of the string to "default". Signed-off-by: Eugene Teo Signed-off-by: Greg Kroah-Hartman commit 35ef2e922ba5829ac754763f67d6f48e8fb6f3da Author: Borislav Petkov Date: Thu Feb 18 19:37:14 2010 +0100 x86, cacheinfo: Enable L3 CID only on AMD commit cb19060abfdecac0d1eb2d2f0e7d6b7a3f8bc4f4 upstream. Final stage linking can fail with arch/x86/built-in.o: In function `store_cache_disable': intel_cacheinfo.c:(.text+0xc509): undefined reference to `amd_get_nb_id' arch/x86/built-in.o: In function `show_cache_disable': intel_cacheinfo.c:(.text+0xc7d3): undefined reference to `amd_get_nb_id' when CONFIG_CPU_SUP_AMD is not enabled because the amd_get_nb_id helper is defined in AMD-specific code but also used in generic code (intel_cacheinfo.c). Reorganize the L3 cache index disable code under CONFIG_CPU_SUP_AMD since it is AMD-only anyway. Signed-off-by: Borislav Petkov LKML-Reference: <20100218184210.GF20473@aftab> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit c72719ee5cf4aa8573b1cba2064f0f31dae50a58 Author: Borislav Petkov Date: Thu Feb 4 12:09:07 2010 +0100 x86, cacheinfo: Remove NUMA dependency, fix for AMD Fam10h rev D1 commit f619b3d8427eb57f0134dab75b0d217325c72411 upstream. The show/store_cache_disable routines depend unnecessarily on NUMA's cpu_to_node and the disabling of cache indices broke when !CONFIG_NUMA. Remove that dependency by using a helper which is always correct. While at it, enable L3 Cache Index disable on rev D1 Istanbuls which sport the feature too. Signed-off-by: Borislav Petkov LKML-Reference: <20100218184339.GG20473@aftab> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 7f5c41a5ff551f3732af815f3c1819df3b48f409 Author: Borislav Petkov Date: Fri Jan 22 16:01:07 2010 +0100 x86, cacheinfo: Calculate L3 indices commit 048a8774ca43488d78605031f11cc206d7a2682a upstream. We need to know the valid L3 indices interval when disabling them over /sysfs. Do that when the core is brought online and add boundary checks to the sysfs .store attribute. Signed-off-by: Borislav Petkov LKML-Reference: <1264172467-25155-6-git-send-email-bp@amd64.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 203dfecb24437869490f160f679cdb5e2140fb4e Author: Borislav Petkov Date: Fri Jan 22 16:01:06 2010 +0100 x86, cacheinfo: Add cache index disable sysfs attrs only to L3 caches commit 897de50e08937663912c86fb12ad7f708af2386c upstream. The cache_disable_[01] attribute in /sys/devices/system/cpu/cpu?/cache/index[0-3]/ is enabled on all cache levels although only L3 supports it. Add it only to the cache level that actually supports it. Signed-off-by: Borislav Petkov LKML-Reference: <1264172467-25155-5-git-send-email-bp@amd64.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 69c30dfc8f13df43a436bbbc6f83dbb0415eca3a Author: Borislav Petkov Date: Fri Jan 22 16:01:04 2010 +0100 intel-agp: Switch to wbinvd_on_all_cpus commit 48a719c238bcbb72d6da79de9c5b3b93ab472107 upstream. Simplify if-statement while at it. [ hpa: we need to #include ] Cc: Dave Jones Cc: David Airlie Signed-off-by: Borislav Petkov LKML-Reference: <1264172467-25155-3-git-send-email-bp@amd64.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 3bbcbfe0684d8cfc08d672567b930a95d0e6e46b Author: Borislav Petkov Date: Fri Jan 22 16:01:05 2010 +0100 x86, cacheinfo: Fix disabling of L3 cache indices commit dcf39daf3d6d97f8741e82f0b9fb7554704ed2d1 upstream. * Correct the masks used for writing the cache index disable indices. * Do not turn off L3 scrubber - it is not necessary. * Make sure wbinvd is executed on the same node where the L3 is. * Check for out-of-bounds values written to the registers. * Make show_cache_disable hex values unambiguous * Check for Erratum #388 Signed-off-by: Borislav Petkov LKML-Reference: <1264172467-25155-4-git-send-email-bp@amd64.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 2444b629ee518745f54c2f7cf9e4de3d48e834cb Author: Borislav Petkov Date: Fri Jan 22 16:01:03 2010 +0100 x86, lib: Add wbinvd smp helpers commit a7b480e7f30b3813353ec009f10f2ac7a6669f3b upstream. Add wbinvd_on_cpu and wbinvd_on_all_cpus stubs for executing wbinvd on a particular CPU. [ hpa: renamed lib/smp.c to lib/cache-smp.c ] [ hpa: wbinvd_on_all_cpus() returns int, but wbinvd() returns void. Thus, the former cannot be a macro for the latter, replace with an inline function. ] Signed-off-by: Borislav Petkov LKML-Reference: <1264172467-25155-2-git-send-email-bp@amd64.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit b98388e5a6d1887a3c96f9543fe79732dd1fc030 Author: Chris Wright Date: Fri Apr 2 18:27:54 2010 -0700 Revert "x86: disable IOMMUs on kernel crash" commit 8f9f55e83e939724490d7cde3833c4883c6d1310 upstream. This effectively reverts commit 61d047be99757fd9b0af900d7abce9a13a337488. Disabling the IOMMU can potetially allow DMA transactions to complete without being translated. Leave it enabled, and allow crash kernel to do the IOMMU reinitialization properly. Cc: Joerg Roedel Cc: Eric Biederman Cc: Neil Horman Cc: Vivek Goyal Signed-off-by: Chris Wright Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit d09556e9407d6e8a29c92a5c16ad32df9996400b Author: Chris Wright Date: Fri Apr 2 18:27:52 2010 -0700 x86/amd-iommu: enable iommu before attaching devices commit 75f66533bc883f761a7adcab3281fe3323efbc90 upstream. Hit another kdump problem as reported by Neil Horman. When initializaing the IOMMU, we attach devices to their domains before the IOMMU is fully (re)initialized. Attaching a device will issue some important invalidations. In the context of the newly kexec'd kdump kernel, the IOMMU may have stale cached data from the original kernel. Because we do the attach too early, the invalidation commands are placed in the new command buffer before the IOMMU is updated w/ that buffer. This leaves the stale entries in the kdump context and can renders device unusable. Simply enable the IOMMU before we do the attach. Cc: Neil Horman Cc: Vivek Goyal Signed-off-by: Chris Wright Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0415a7a7068c9cb7d5b34d3a5141a0b87dea8cf7 Author: Joerg Roedel Date: Mon Mar 8 14:20:07 2010 +0100 x86/amd-iommu: Use helper function to destroy domain commit 8b408fe4f853dcfa18d133aa4cf1d7546b4c3870 upstream. In the amd_iommu_domain_destroy the protection_domain_free function is partly reimplemented. The 'partly' is the bug here because the domain is not deleted from the domain list. This results in use-after-free errors and data-corruption. Fix it by just using protection_domain_free instead. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 089017d7f11ae1deef16bbd08d7536c13954ebbc Author: Dave Airlie Date: Mon Apr 19 17:54:31 2010 +1000 drm/radeon/kms: add FireMV 2400 PCI ID. commit 79b9517a33a283c5d9db875c263670ed1e055f7e upstream. This is an M24/X600 chip. From RH# 581927 Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit b2a7a6d4fa2b30043b0584904d1b19be6240defb Author: Jerome Glisse Date: Fri Apr 16 18:46:35 2010 +0200 drm/radeon/kms: fix rs600 tlb flush commit 30f69f3fb20bd719b5e1bf879339914063d38f47 upstream. Typo in in flush leaded to no flush of the RS600 tlb which ultimately leaded to massive system ram corruption, with this patch everythings seems to work properly. Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 1ffdb5a3454e8063bfee1257dddb5eeb2add85ae Author: Alex Deucher Date: Thu Apr 15 13:31:12 2010 -0400 drm/radeon/kms: fix tv dac conflict resolver commit 08d075116db3592db218bfe0f554cd93c9e12505 upstream. On systems with the tv dac shared between DVI and TV, we can only use the dac for one of the connectors. However, when using a digital monitor on the DVI port, you can use the dac for the TV connector just fine. Check the use_digital status when resolving the conflict. Fixes fdo bug 27649, possibly others. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 84dd80b43dbb946ad5df18e37788bf334543cf83 Author: Alex Deucher Date: Tue Apr 13 11:21:59 2010 -0400 drm/radeon/kms: disable the tv encoder when tv/cv is not in use commit d3a67a43b0460bae3e2ac14092497833344ac10d upstream. Switching between TV and VGA caused VGA to break on some systems since the TV encoder was left enabled when VGA was used. fixes fdo bug 25520. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2f2efe38d1da236b3509aa4af0bdc6fdfb22bf0b Author: Stefan Bader Date: Mon Mar 29 17:53:12 2010 +0200 drm/i915: Add no_lvds entry for the Clientron U800 commit 9875557ee8247c3f7390d378c027b45c7535a224 upstream. BugLink: http://bugs.launchpad.net/ubuntu/bugs/544671 This system claims to have a LVDS but has not. Signed-off-by: Stephane Graber Signed-off-by: Stefan Bader Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 03c537ee0e487507cb9fa4e59a8cd8ea307c23dc Author: Jean Delvare Date: Wed Apr 14 16:14:08 2010 +0200 hwmon: (sht15) Properly handle the case CONFIG_REGULATOR=n commit c7a78d2c2e2537fd24903e966f34aae50319d587 upstream. When CONFIG_REGULATOR isn't set, regulator_get_voltage() returns 0. Properly handle this case by not trusting the value. Reported-by: Jerome Oufella Signed-off-by: Jean Delvare Cc: Jonathan Cameron Acked-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7fc829f5018cc20e12d25811d15a2d171225a7da Author: Jerome Oufella Date: Wed Apr 14 16:14:07 2010 +0200 hwmon: (sht15) Fix sht15_calc_temp interpolation function commit 328a2c22abd08911e37fa66f1358f829cecd72e9 upstream. I discovered two issues. First the previous sht15_calc_temp() loop did not iterate through the temppoints array since the (data->supply_uV > temppoints[i - 1].vdd) test is always true in this direction. Also the two-points linear interpolation function was returning biased values due to a stray division by 1000 which shouldn't be there. [JD: Also change the default value for d1 from 0 to something saner.] Signed-off-by: Jerome Oufella Acked-by: Jonathan Cameron Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 8b49768d5fd8f4365fd9de0151c3c4190e9aa4e3 Author: Takashi Iwai Date: Sat Apr 10 21:27:23 2010 +0200 ALSA: usb - Fix Oops after usb-midi disconnection commit 29aac005ff4dc8a5f50b80f4e5c4f59b21c0fb50 upstream. usb-midi causes sometimes Oops at snd_usbmidi_output_drain() after disconnection. This is due to the access to the endpoints which have been already released at disconnection while the files are still alive. This patch fixes the problem by checking disconnection state at snd_usbmidi_output_drain() and by releasing urbs but keeping the endpoint instances until really all freed. Tested-by: Tvrtko Ursulin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 017583503d42172a6d1759eb08bfabbb4d462894 Author: Joerg Schirottke Date: Thu Apr 15 08:37:41 2010 +0200 ALSA: hda - add a quirk for Clevo M570U laptop commit d1501ea844eefdf925f6b711875b4b2b928fddf8 upstream. Added the matching model for Clevo laptop M570U. Signed-off-by: Joerg Schirottke Tested-by: Maximilian Gerhard Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5eb54e380090d45afc9e4484abd6a75bd6ae4bc2 Author: Trond Myklebust Date: Sun Apr 11 16:48:44 2010 -0400 NFSv4: fix delegated locking commit 0df5dd4aae211edeeeb84f7f84f6d093406d7c22 upstream. Arnaud Giersch reports that NFSv4 locking is broken when we hold a delegation since commit 8e469ebd6dc32cbaf620e134d79f740bf0ebab79 (NFSv4: Don't allow posix locking against servers that don't support it). According to Arnaud, the lock succeeds the first time he opens the file (since we cannot do a delegated open) but then fails after we start using delegated opens. The following patch fixes it by ensuring that locking behaviour is governed by a per-filesystem capability flag that is initially set, but gets cleared if the server ever returns an OPEN without the NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set. Reported-by: Arnaud Giersch Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 2d71e7c297ba7fdce9ff2084f2873fef66f2fb17 Author: Trond Myklebust Date: Thu Mar 25 13:51:05 2010 -0400 NFSv4: Fall back to ordinary lookup if nfs4_atomic_open() returns EISDIR commit 80e60639f1b7c121a7fea53920c5a4b94009361a upstream. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 20580fe38431aead39320ac7a8ff201e1f8744af Author: Anton Blanchard Date: Tue Apr 6 17:02:19 2010 +1000 sched: Fix sched_getaffinity() commit 84fba5ec91f11c0efb27d0ed6098f7447491f0df upstream. taskset on 2.6.34-rc3 fails on one of my ppc64 test boxes with the following error: sched_getaffinity(0, 16, 0x10029650030) = -1 EINVAL (Invalid argument) This box has 128 threads and 16 bytes is enough to cover it. Commit cd3d8031eb4311e516329aee03c79a08333141f1 (sched: sched_getaffinity(): Allow less than NR_CPUS length) is comparing this 16 bytes agains nr_cpu_ids. Fix it by comparing nr_cpu_ids to the number of bits in the cpumask we pass in. Signed-off-by: Anton Blanchard Reviewed-by: KOSAKI Motohiro Cc: Sharyathi Nagesh Cc: Ulrich Drepper Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Jack Steiner Cc: Russ Anderson Cc: Mike Travis LKML-Reference: <20100406070218.GM5594@kryten> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2639e82ed79e6f639b1654031e497060e8195c00 Author: KOSAKI Motohiro Date: Fri Mar 12 16:15:36 2010 +0900 sched: sched_getaffinity(): Allow less than NR_CPUS length commit cd3d8031eb4311e516329aee03c79a08333141f1 upstream. [ Note, this commit changes the syscall ABI for > 1024 CPUs systems. ] Recently, some distro decided to use NR_CPUS=4096 for mysterious reasons. Unfortunately, glibc sched interface has the following definition: # define __CPU_SETSIZE 1024 # define __NCPUBITS (8 * sizeof (__cpu_mask)) typedef unsigned long int __cpu_mask; typedef struct { __cpu_mask __bits[__CPU_SETSIZE / __NCPUBITS]; } cpu_set_t; It mean, if NR_CPUS is bigger than 1024, cpu_set_t makes an ABI issue ... More recently, Sharyathi Nagesh reported following test program makes misterious syscall failure: ----------------------------------------------------------------------- #define _GNU_SOURCE #include #include #include int main() { cpu_set_t set; if (sched_getaffinity(0, sizeof(cpu_set_t), &set) < 0) printf("\n Call is failing with:%d", errno); } ----------------------------------------------------------------------- Because the kernel assumes len argument of sched_getaffinity() is bigger than NR_CPUS. But now it is not correct. Now we are faced with the following annoying dilemma, due to the limitations of the glibc interface built in years ago: (1) if we change glibc's __CPU_SETSIZE definition, we lost binary compatibility of _all_ application. (2) if we don't change it, we also lost binary compatibility of Sharyathi's use case. Then, I would propse to change the rule of the len argument of sched_getaffinity(). Old: len should be bigger than NR_CPUS New: len should be bigger than maximum possible cpu id This creates the following behavior: (A) In the real 4096 cpus machine, the above test program still return -EINVAL. (B) NR_CPUS=4096 but the machine have less than 1024 cpus (almost all machines in the world), the above can run successfully. Fortunatelly, BIG SGI machine is mainly used for HPC use case. It means they can rebuild their programs. IOW we hope they are not annoyed by this issue ... Reported-by: Sharyathi Nagesh Signed-off-by: KOSAKI Motohiro Acked-by: Ulrich Drepper Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Cc: Jack Steiner Cc: Russ Anderson Cc: Mike Travis LKML-Reference: <20100312161316.9520.A69D9226@jp.fujitsu.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4a10e129667758c3986835f1e733a3f4d8039de3 Author: Suresh Siddha Date: Wed Mar 31 18:04:47 2010 -0700 x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boards commit 472a474c6630efd195d3738339fd1bdc8aa3b1aa upstream. Jan Grossmann reported kernel boot panic while booting SMP kernel on his system with a single core cpu. SMP kernels call enable_IR_x2apic() from native_smp_prepare_cpus() and on platforms where the kernel doesn't find SMP configuration we ended up again calling enable_IR_x2apic() from the APIC_init_uniprocessor() call in the smp_sanity_check(). Thus leading to kernel panic. Don't call enable_IR_x2apic() and default_setup_apic_routing() from APIC_init_uniprocessor() in CONFIG_SMP case. NOTE: this kind of non-idempotent and assymetric initialization sequence is rather fragile and unclean, we'll clean that up in v2.6.35. This is the minimal fix for v2.6.34. Reported-by: Jan.Grossmann@kielnet.net Signed-off-by: Suresh Siddha Cc: Cc: Cc: Cc: Cc: LKML-Reference: <1270083887.7835.78.camel@sbs-t61.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 35b99e935ed2809d03be8cdeb2f96d9d4faeb5c1 Author: Pallipadi, Venkatesh Date: Thu Feb 25 10:53:48 2010 -0800 x86, hpet: Erratum workaround for read after write of HPET comparator commit 8da854cb02156c90028233ae1e85ce46a1d3f82c upstream. On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote: > Hello, > > Again, on the Intel DP55KG board: > > # uname -a > Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux > > [ 1.237600] ------------[ cut here ]------------ > [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80() > [ 1.238221] Hardware name: > [ 1.238504] hpet: compare register read back failed. > [ 1.238793] Modules linked in: > [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1 > [ 1.239605] Call Trace: > [ 1.239886] [] ? warn_slowpath_common+0x73/0xb0 > [ 1.240409] [] ? tick_dev_program_event+0x38/0xc0 > [ 1.240699] [] ? warn_slowpath_fmt+0x40/0x50 > [ 1.240992] [] ? tick_dev_program_event+0x38/0xc0 > [ 1.241281] [] ? hpet_next_event+0x70/0x80 > [ 1.241573] [] ? tick_dev_program_event+0x38/0xc0 > [ 1.241859] [] ? tick_handle_oneshot_broadcast+0xe2/0x100 > [ 1.246533] [] ? timer_interrupt+0x1a/0x30 > [ 1.246826] [] ? handle_IRQ_event+0x39/0xd0 > [ 1.247118] [] ? handle_edge_irq+0xb8/0x160 > [ 1.247407] [] ? handle_irq+0x15/0x20 > [ 1.247689] [] ? do_IRQ+0x62/0xe0 > [ 1.247976] [] ? ret_from_intr+0x0/0xa > [ 1.248262] [] ? mwait_idle+0x57/0x80 > [ 1.248796] [] ? cpu_idle+0x5c/0xb0 > [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]--- > > Is this something Intel has to fix or is it a bug in the kernel? This is a chipset erratum. Thomas: You mentioned we can retain this check only for known-buggy and hpet debug kind of options. But here is the simple workaround patch for this particular erratum. Some chipsets have a erratum due to which read immediately following a write of HPET comparator returns old comparator value instead of most recently written value. Erratum 15 in "Intel I/O Controller Hub 9 (ICH9) Family Specification Update" (http://www.intel.com/assets/pdf/specupdate/316973.pdf) Workaround for the errata is to read the comparator twice if the first one fails. Signed-off-by: Venkatesh Pallipadi LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com> Signed-off-by: H. Peter Anvin Cc: Venkatesh Pallipadi Signed-off-by: Greg Kroah-Hartman commit 0584aa8dea3dab7f49ce949f61d7ec92b6b29e3e Author: Thomas Gleixner Date: Fri Nov 27 15:24:44 2009 +0100 x86: hpet: Make WARN_ON understandable commit 18ed61da985c57eea3fe8038b13fa2837c9b3c3f upstream. Andrew complained rightly that the WARN_ON in hpet_next_event() is confusing and the code comment not really helpful. Change it to WARN_ONCE and print the reason in clear text. Change the comment to explain what kind of hardware wreckage we deal with. Pointed-out-by: Andrew Morton Signed-off-by: Thomas Gleixner Cc: Venki Pallipadi Signed-off-by: Greg Kroah-Hartman commit 342fcebe9ef1013a6b655875d2272c2078c6355e Author: Shaohua Li Date: Fri Mar 5 08:59:32 2010 +0800 x86-32, resume: do a global tlb flush in S4 resume commit 8ae06d223f8203c72104e5c0c4ee49a000aedb42 upstream. Colin King reported a strange oops in S4 resume code path (see below). The test system has i5/i7 CPU. The kernel doesn't open PAE, so 4M page table is used. The oops always happen a virtual address 0xc03ff000, which is mapped to the last 4k of first 4M memory. Doing a global tlb flush fixes the issue. EIP: 0060:[] EFLAGS: 00010086 CPU: 0 EIP is at copy_loop+0xe/0x15 EAX: 36aeb000 EBX: 00000000 ECX: 00000400 EDX: f55ad46c ESI: 0f800000 EDI: c03ff000 EBP: f67fbec4 ESP: f67fbea8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 ... ... CR2: 00000000c03ff000 Tested-by: Colin Ian King Signed-off-by: Shaohua Li LKML-Reference: <20100305005932.GA22675@sli10-desk.sh.intel.com> Acked-by: Rafael J. Wysocki Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 94ca1d6aa6cd689ccfaeab1be75384b80e988d91 Author: Alex Deucher Date: Mon Apr 5 23:57:52 2010 -0400 drm/radeon/kms: fix washed out image on legacy tv dac commit 643acacf02679befd0f98ac3c5fecb805f1c9548 upstream. bad cast was overwriting the tvdac adj values Fixes fdo bug 27478 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0119701ec6ef9f8b1aba8c82e02661975d915789 Author: Michel Dänzer Date: Fri Apr 2 16:59:06 2010 +0000 drm/radeon: R300 AD only has one quad pipe. commit 57b54ea6b7863ccfeb41851b5f58f9fd1b83c79e upstream. Gleaned from the Mesa code. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=27355 . Signed-off-by: Michel Dänzer Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 05bb71ee8ed003b32afec9ab082e21ac85249324 Author: Adam Jackson Date: Tue Apr 6 16:11:00 2010 +0000 drm/edid/quirks: Envision EN2028 commit ba1163de2f74d624e7b0e530c4104c98ede0045a upstream. Claims 1280x1024 preferred, physically 1600x1200 cf. http://bugzilla.redhat.com/530399 Signed-off-by: Adam Jackson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 22ae5dd50967f1b9fb6c59715760a139f6e7e67c Author: Rabin Vincent Date: Wed Apr 7 18:10:20 2010 +0100 ARM: 6031/1: fix Thumb-2 decompressor commit d4d9959c099751158c5cf14813fe378e206339c6 upstream. 98e12b5a6e05413 ("ARM: Fix decompressor's kernel size estimation for ROM=y") broke the Thumb-2 decompressor because it added an entry in the LC0 table but didn't adjust the offset the Thumb-2 code uses to load the SP from that table. Fix it. Signed-off-by: Rabin Vincent Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 485f88310f3216db5bbbfadaf8bb5049ea606f86 Author: Wey-Yi Guy Date: Thu Apr 8 13:17:37 2010 -0700 iwlwifi: need check for valid qos packet before free commit ece6444c2fe80dab679beb5f0d58b091f1933b00 upstream. For 4965, need to check it is valid qos frame before free, only valid QoS frame has the tid used to free the packets. Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8a832806f94a204b9ddc9010fe8ddf15f7ad842f Author: Steve French Date: Sat Apr 3 17:20:21 2010 +0000 CIFS: initialize nbytes at the beginning of CIFSSMBWrite() commit a24e2d7d8f512340991ef0a59cb5d08d491b8e98 upstream. By doing this we always overwrite nbytes value that is being passed on to CIFSSMBWrite() and need not rely on the callers to initialize. CIFSSMBWrite2 is doing this already. Reviewed-by: Shirish Pargaonkar Reviewed-by: Jeff Layton Signed-off-by: Suresh Jayaraman Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2aa9e27ee0822cffc19e9b976daff7eb0c48b023 Author: Suresh Jayaraman Date: Wed Mar 31 12:00:03 2010 +0530 cifs: Fix a kernel BUG with remote OS/2 server (try #3) commit 6513a81e9325d712f1bfb9a1d7b750134e49ff18 upstream. While chasing a bug report involving a OS/2 server, I noticed the server sets pSMBr->CountHigh to a incorrect value even in case of normal writes. This results in 'nbytes' being computed wrongly and triggers a kernel BUG at mm/filemap.c. void iov_iter_advance(struct iov_iter *i, size_t bytes) { BUG_ON(i->count < bytes); <--- BUG here Why the server is setting 'CountHigh' is not clear but only does so after writing 64k bytes. Though this looks like the server bug, the client side crash may not be acceptable. The workaround is to mask off high 16 bits if the number of bytes written as returned by the server is greater than the bytes requested by the client as suggested by Jeff Layton. Reviewed-by: Jeff Layton Signed-off-by: Suresh Jayaraman Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6bad96122d88b8d053d453fe4da5ee557911e086 Author: Tejun Heo Date: Mon Apr 5 10:51:26 2010 +0900 libata: disable NCQ on Crucial C300 SSD commit 68b0ddb289220b6d4d865be128939663be34959d upstream. Crucial said, Thank you for contacting us. We know that with our M225 line of SSDs you sometimes need to disable NCQ (native command queuing) to avoid just the type of errors you're seeing. Our recommendation for the M225 is to add libata.force=noncq to your Linux kernel boot options, under the kernel ATA library option. I have sent your feedback to the engineers working on the C300, and asked them to please pass it on to the firmware team. I have been notified that they are in the process of testing and finalizing a new firmware version, that you can expect to see released around the end of April. We’ll keep you posted as to when it will be available for download. So, turn off NCQ on the drive w/ the current firmware revision. Reported in the following bug. https://bugzilla.kernel.org/show_bug.cgi?id=15573 Signed-off-by: Tejun Heo Reported-by: lethalwp@scarlet.be Reported-by: Luke Macken Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 542ce471980faba988bbb51043b7d2ff4d848e80 Author: Alan Jenkins Date: Sat Feb 20 11:02:24 2010 +0000 eeepc-laptop: disable wireless hotplug for 1005PE commit ced69c59811f05b2f8378467cbb82ac6ed3c6a5a upstream. The wireless hotplug code is not needed on this model, and it disables the wired ethernet card. (Like on the 1005HA and 1201N). References: [bwh: Backported to 2.6.32] Signed-off-by: Alan Jenkins Reported-by: Ansgar Burchardt Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 9768e362e9e2631310c5e97e81b6d892a260dca3 Author: Corentin Chary Date: Wed Jan 6 22:07:41 2010 +0100 eeepc-laptop: disable wireless hotplug for 1201N commit 4194e2f551a6308e6ab34ac88210bf54858aa7df upstream. [bwh: Backported to 2.6.32] Signed-off-by: Corentin Chary Signed-off-by: Len Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 7dacd955257774668de0e4416f0a9255a2435daa Author: Corentin Chary Date: Wed Jan 6 22:07:40 2010 +0100 eeepc-laptop: add hotplug_disable parameter commit 322a1356be96bcc4b97e8e370f6468c821330077 upstream. Some new models need to disable wireless hotplug. For the moment, we don't know excactly what models need that, except 1005HA. Users will be able to use that param as a workaround. [bwh: Backported to 2.6.32] Signed-off-by: Corentin Chary Signed-off-by: Len Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 6f5be98e8285a4ce38387e76b8c8ebe8af6b8770 Author: Corentin Chary Date: Wed Jan 6 22:07:38 2010 +0100 eeepc-laptop: dmi blacklist to disable pci hotplug code commit 10ae4b5663ff3092553bfbd867e7bd474ce6c553 upstream. This is a short term workaround for Eeepc 1005HA. refs: [bwh: Backported to 2.6.32] Signed-off-by: Corentin Chary Signed-off-by: Len Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit e3e4ad689878ad11768cd573e88ce9c45b200c9f Author: Alan Jenkins Date: Wed Jan 6 22:07:37 2010 +0100 eeepc-laptop: disable cpu speed control on EeePC 701 commit da8ba01deb98f3dc0558b1f5a37e64f40bba7904 upstream. The EeePC 4G ("701") implements CFVS, but it is not supported by the pre-installed OS, and the original option to change it in the BIOS setup screen was removed in later versions. Judging by the lack of "Super Hybrid Engine" on Asus product pages, this applies to all "701" models (4G/4G Surf/2G Surf). So Asus made a deliberate decision not to support it on this model. We have several reports that using it can cause the system to hang [1]. That said, it does not happen all the time. Some users do not experience it at all (and apparently wish to continue "right-clocking"). Check for the EeePC 701 using DMI. If met, then disable writes to the "cpufv" sysfs attribute and log an explanatory message. Add a "cpufv_disabled" attribute which allow users to override this policy. Writing to this attribute will log a second message. The sysfs attribute is more useful than a module option, because it makes it easier for userspace scripts to provide consistent behaviour (according to user configuration), regardless of whether the kernel includes this change. [1] [bwh: Backported to 2.6.32] Signed-off-by: Alan Jenkins Signed-off-by: Corentin Chary Signed-off-by: Len Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 1b0d63f15fb79d0cb840f8b701f343548b5640e8 Author: Henrique de Moraes Holschuh Date: Thu Feb 25 22:22:22 2010 -0300 thinkpad-acpi: lock down video output state access commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream. Given the right combination of ThinkPad and X.org, just reading the video output control state is enough to hard-crash X.org. Until the day I somehow find out a model or BIOS cut date to not provide this feature to ThinkPads that can do video switching through X RandR, change permissions so that only processes with CAP_SYS_ADMIN can access any sort of video output control state. This bug could be considered a local DoS I suppose, as it allows any non-privledged local user to cause some versions of X.org to hard-crash some ThinkPads. Reported-by: Jidanni Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Greg Kroah-Hartman commit a772b90083481bd87458f48641dd7ba9e2401393 Author: Alexey Dobriyan Date: Tue Dec 15 21:51:12 2009 -0200 thinkpad-acpi: convert to seq_file commit 887965e6576a78f71b9b98dec43fd1c73becd2e8 upstream. (hmh@hmh.eng.br: Updated to apply to 2.6.32.y) Signed-off-by: Alexey Dobriyan Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 8708a3e873490a93154f79ebbb7cb3c09a58b596 Author: Henrique de Moraes Holschuh Date: Tue Dec 15 21:51:07 2009 -0200 thinkpad-acpi: log initial state of rfkill switches commit 5451a923bbdcff6ae665947e120af7238b21a9d2 upstream. We already log the initial state of the hardware rfkill switch (WLSW), might as well log the state of the softswitches as well. Signed-off-by: Henrique de Moraes Holschuh Cc: Josip Rodin Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit adc0e83806464b3bc3ba78d99c148dfd49122715 Author: Henrique de Moraes Holschuh Date: Tue Dec 15 21:51:06 2009 -0200 thinkpad-acpi: sync input device EV_SW initial state commit d89a727aff649f6768f7a34ee57f031ebf8bab4c upstream. Before we register the input device, sync the input layer EV_SW state through a call to input_report_switch(), to avoid issuing a gratuitous event for the initial state of these switches. This fixes some annoyances caused by the interaction with rfkill and EV_SW SW_RFKILL_ALL events. Reported-by: Kevin Locke Signed-off-by: Henrique de Moraes Holschuh Cc: Alan Jenkins Cc: Johannes Berg Cc: Dmitry Torokhov Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit da72e178aa50a69a159ddd8970ee3b947753a449 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:29 2009 +0000 thinkpad-acpi: use input_set_capability commit 792979c8032b8f5adb77ea986db7082fff04c8e7 upstream. Use input_set_capability() instead of set_bit. Signed-off-by: Henrique de Moraes Holschuh Cc: Dmitry Torokhov Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit c5936b5ec21dc66234b1f7d3675d4a8f41cb2733 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:28 2009 +0000 thinkpad-acpi: log temperatures on termal alarm (v2) commit 9ebd9e833648745fa5ac6998b9e0153ccd3ba839 upstream. Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Signed-off-by: Henrique de Moraes Holschuh Acked-by: Pavel Machek Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 6bc3995a644b0085564349c85251624d46328bf1 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:27 2009 +0000 thinkpad-acpi: expose module parameters commit b09c72259e88cec3d602aef987a3209297f3a9c2 upstream. Export the normal (non-command) module paramenters as mode 0444, so that they will show up in sysfs. These parameters must not be changed at runtime as a rule, with very few exceptions. Reported-by: Ferenc Wagner Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 9eeffc8d8d7a7e078b977b195926b611f5d4edf4 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:26 2009 +0000 thinkpad-acpi: adopt input device commit d112ef95d4ec1ee7fe7123e3f21e4aac0d57570c upstream. Properly init the parent field of the input device. Thanks to Alan Jenkins, who noted this problem in a different driver. Reported-by: Alan Jenkins Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 5d0e3bb2aa35bc12469cb2c67d60b513e7e7fcb3 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:25 2009 +0000 thinkpad-acpi: silence bogus complain during rmmod commit 6b30eb7d211840ba1a03f855d9e7b80a921368f2 upstream. Fix this bogus warning during module shutdown, when backlight event reporting is enabled: "thinkpad_acpi: required events 0x00018000 not enabled!" Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 8bf934d74b1e22fbf206a163653915a12ab67350 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:24 2009 +0000 thinkpad-acpi: issue backlight class events commit 347a26860e2293b1347996876d3550499c7bb31f upstream. Take advantage of the new events capabilities of the backlight class to notify userspace of backlight changes. This depends on "backlight: Allow drivers to update the core, and generate events on changes", by Matthew Garrett. Signed-off-by: Henrique de Moraes Holschuh Cc: Matthew Garrett Cc: Richard Purdie Signed-off-by: Len Brown commit 501a0633225f8b6b187a110061d439f524ffb7b8 Author: Henrique de Moraes Holschuh Date: Wed Dec 9 01:36:23 2009 +0000 thinkpad-acpi: fix some version quirks commit 90765c6aee568137521ba19347c744b5abde8161 upstream. Update some of the BIOS/EC version quirks. Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 2e1d87a5bde1976c33a921a7056eac87bfe9fc18 Author: Eric Sandeen Date: Mon Nov 16 16:27:30 2009 -0600 ext3: journal all modifications in ext3_xattr_set_handle commit d965736b8cb42ae51ba9c3f13488035a98d025c6 upstream. ext3_xattr_set_handle() was zeroing out an inode outside of journaling constraints; this is one of the accesses that was causing the crc errors in journal replay as seen in kernel.org bugzilla #14354. Although ext3 doesn't have the crc issue, modifications out of journal control are a Bad Thing. Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit c39de9325438aa053afb3575edf9a1bd83d65819 Author: Eric Sandeen Date: Mon Nov 16 16:34:51 2009 -0600 ext3: Don't update the superblock in ext3_statfs() commit b918397542388de75bd86c32fbfa820e5d629fa9 upstream. commit a71ce8c6c9bf269b192f352ea555217815cf027e updated ext3_statfs() to update the on-disk superblock counters, but modified this buffer directly without any journaling of the change. This is one of the accesses that was causing the crc errors in journal replay as seen in kernel.org bugzilla #14354. The modifications were originally to keep the sb "more" in sync, so that a readonly fsck of the device didn't flag this as an error (as often), but apparently e2fsprogs deals with this differently now, anyway. Based on Ted's patch for ext4, which was in turn based on my work on that bug and another preliminary patch... Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 4ce89d53dc204c6ab6a6c14049cddb26738001fe Author: JosephChan@via.com.tw Date: Fri Mar 19 14:08:11 2010 +0800 pata_via: Add VIA VX900 support commit 4f1deba435ef75380c1d06fda860c7a15ea16fdf upstream. Signed-off-by: Joseph Chan Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit c72a8076fc664e019ceac47b91d0e056137d0d7b Author: Marcelo Tosatti Date: Fri Mar 19 15:47:39 2010 +0100 KVM: x86: disable paravirt mmu reporting commit a68a6a7282373bedba8a2ed751b6384edb983a64 upstream Disable paravirt MMU capability reporting, so that new (or rebooted) guests switch to native operation. Paravirt MMU is a burden to maintain and does not bring significant advantages compared to shadow anymore. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 926fd42e594095f1967b6df75f3db82a1988c58d Author: Sheng Yang Date: Fri Mar 19 15:47:38 2010 +0100 KVM: VMX: Disable unrestricted guest when EPT disabled commit 046d87103addc117f0d397196e85189722d4d7de upstream Otherwise would cause VMEntry failure when using ept=0 on unrestricted guest supported processors. Signed-off-by: Sheng Yang Signed-off-by: Marcelo Tosatti Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit e075e2caebf932a85786e6d5eb544ee4b0e1441e Author: Eduardo Habkost Date: Fri Mar 19 15:47:37 2010 +0100 KVM: SVM: Reset cr0 properly on vcpu reset commit 18fa000ae453767b59ab97477925895a3f0c46ea upstream svm_vcpu_reset() was not properly resetting the contents of the guest-visible cr0 register, causing the following issue: https://bugzilla.redhat.com/show_bug.cgi?id=525699 Without resetting cr0 properly, the vcpu was running the SIPI bootstrap routine with paging enabled, making the vcpu get a pagefault exception while trying to run it. Instead of setting vmcb->save.cr0 directly, the new code just resets kvm->arch.cr0 and calls kvm_set_cr0(). The bits that were set/cleared on vmcb->save.cr0 (PG, WP, !CD, !NW) will be set properly by svm_set_cr0(). kvm_set_cr0() is used instead of calling svm_set_cr0() directly to make sure kvm_mmu_reset_context() is called to reset the mmu to nonpaging mode. Signed-off-by: Eduardo Habkost Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 5b4ce46f453bb83ce2e382ecccdb89d4920bc613 Author: Eduardo Habkost Date: Fri Mar 19 15:47:36 2010 +0100 KVM: VMX: Use macros instead of hex value on cr0 initialization commit fa40052ca04bdbbeb20b839cc8ffe9fa7beefbe9 upstream This should have no effect, it is just to make the code clearer. Signed-off-by: Eduardo Habkost Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 86143fe846043179825406134ae375c2efd9c072 Author: Jan Kiszka Date: Fri Mar 19 15:47:35 2010 +0100 KVM: VMX: Update instruction length on intercepted BP commit c573cd22939e54fc1b8e672054a505048987a7cb upstream We intercept #BP while in guest debugging mode. As VM exits due to intercepted exceptions do not necessarily come with valid idt_vectoring, we have to update event_exit_inst_len explicitly in such cases. At least in the absence of migration, this ensures that re-injections of #BP will find and use the correct instruction length. Signed-off-by: Jan Kiszka Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 78ce64a384f12bcd4cbfc1de3db4e53c592fc5a8 Author: Gleb Natapov Date: Fri Mar 19 15:47:34 2010 +0100 KVM: Fix segment descriptor loading commit c697518a861e6c43b92b848895f9926580ee63c3 upstream Add proper error and permission checking. This patch also change task switching code to load segment selectors before segment descriptors, like SDM requires, otherwise permission checking during segment descriptor loading will be incorrect. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit ad66f35eaafb1026d96a6231761d3be3f58edec8 Author: Gleb Natapov Date: Fri Mar 19 15:47:33 2010 +0100 KVM: x86 emulator: Fix popf emulation commit d4c6a1549c056f1d817e8f6f2f97d8b44933472f upstream POPF behaves differently depending on current CPU mode. Emulate correct logic to prevent guest from changing flags that it can't change otherwise. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit f6eb212e6056e62841e347e141285aed8920a731 Author: Gleb Natapov Date: Fri Mar 19 15:47:32 2010 +0100 KVM: x86 emulator: Check IOPL level during io instruction emulation commit f850e2e603bf5a05b0aee7901857cf85715aa694 upstream Make emulator check that vcpu is allowed to execute IN, INS, OUT, OUTS, CLI, STI. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 2f4415466842f786b38bd28dcaf7c85b2f7a9c8f Author: Gleb Natapov Date: Fri Mar 19 15:47:31 2010 +0100 KVM: x86 emulator: fix memory access during x86 emulation commit 1871c6020d7308afb99127bba51f04548e7ca84e upstream Currently when x86 emulator needs to access memory, page walk is done with broadest permission possible, so if emulated instruction was executed by userspace process it can still access kernel memory. Fix that by providing correct memory access to page walker during emulation. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 10a505e60e897f3f4efaf8dbe9db40b3cdca23b4 Author: Gleb Natapov Date: Fri Mar 19 15:47:30 2010 +0100 KVM: x86 emulator: Add Virtual-8086 mode of emulation commit a0044755679f3e761b8b95995e5f2db2b7efd0f6 upstream For some instructions CPU behaves differently for real-mode and virtual 8086. Let emulator know which mode cpu is in, so it will not poke into vcpu state directly. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 5774cdfd3d81b8ce75be512c180dd7bd5bf5b81c Author: Evan McClain Date: Tue Mar 9 19:20:58 2010 -0500 backlight: mbp_nvidia_bl - add five more MacBook variants commit 36bc5ee6a8d13333980fa54e97d3469d3d4cda98 upstream. This adds the MacBook 1,1 2,1 3,1 4,1 and 4,2 to the DMI tables. Signed-off-by: Evan McClain Signed-off-by: Richard Purdie Signed-off-by: Greg Kroah-Hartman commit 6abbc7bac8ea5e3210935867b32c65d402dcb7fb Author: Jiri Slaby Date: Fri Mar 19 02:51:56 2010 +0100 resource: move kernel function inside __KERNEL__ commit 96d07d211739fd2450ac54e81d00fa40fcd4b1bd upstream From: Jiri Slaby resource: move kernel function inside __KERNEL__ It is an internal function. Move it inside __KERNEL__ ifdef, along with task_struct declaration. Then we get: #--- /usr/include/linux/resource.h 2009-09-14 15:09:29.000000000 +0200 #+++ usr/include/linux/resource.h 2010-01-04 11:30:54.000000000 +0100 #@@ -3,8 +3,6 @@ # ##include # #-struct task_struct; #- #/* #* Resource control/accounting header file for linux #*/ #@@ -70,6 +68,5 @@ #*/ ##include # #-int getrusage(struct task_struct *p, int who, struct rusage *ru); # ##endif # #*********** include/linux/Kbuild is untouched, since unifdef is run even on headers-y nowadays. backport to 2.6.32 by maximilian attems Patch commented out by gregkh due to quilt complaining. Signed-off-by: Jiri Slaby Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 787814b206766e5a6f21aa2aac0c6685b46821d3 Author: Andreas Herrmann Date: Wed Dec 16 15:43:55 2009 +0100 x86, amd: Get multi-node CPU info from NodeId MSR instead of PCI config space commit 9d260ebc09a0ad6b5c73e17676df42c7bc75ff64 upstream. Use NodeId MSR to get NodeId and number of nodes per processor. Signed-off-by: Andreas Herrmann LKML-Reference: <20091216144355.GB28798@alberich.amd.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 97d0f3f2a0bd5c346449a61a77dc1d140ca3782f Author: Daniel T Chen Date: Tue Mar 30 13:29:28 2010 -0400 ALSA: hda: Fix 0 dB offset for Lenovo Thinkpad models using AD1981 commit b8e80cf386419453678b01bef830f53445ebb15d upstream. BugLink: https://launchpad.net/bugs/551606 The OR's hardware distorts at PCM 100% because it does not correspond to 0 dB. Fix this in patch_ad1981() for all models using the Thinkpad quirk. Reported-by: Jane Silber Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit db27624dc7355321d86825e29ffcff6c4bc2e87c Author: Dan Carpenter Date: Tue Apr 6 19:31:26 2010 +0300 ALSA: mixart: range checking proc file commit b0cc58a25d04160d39a80e436847eaa2fbc5aa09 upstream. The original code doesn't take into consideration that the value of MIXART_BA0_SIZE - pos can be less than zero which would lead to a large unsigned value for "count". Also I moved the check that read size is a multiple of 4 bytes below the code that adjusts "count". Signed-off-by: Dan Carpenter Acked-by: Linus Torvalds Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a54573d774735cc1f9d0e3bbf2c197c2d9523fe8 Author: Wu Fengguang Date: Tue Apr 6 14:34:53 2010 -0700 readahead: fix NULL filp dereference commit 70655c06bd3f25111312d63985888112aed15ac5 upstream. btrfs relocate_file_extent_cluster() calls us with NULL filp: [ 4005.426805] BUG: unable to handle kernel NULL pointer dereference at 00000021 [ 4005.426818] IP: [] page_cache_sync_readahead+0x18/0x3e Signed-off-by: Wu Fengguang Cc: Yan Zheng Reported-by: Kirill A. Shutemov Tested-by: Kirill A. Shutemov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 957c93832c0f484ced1fbeca058375fa939b0ff9 Author: Anton Blanchard Date: Tue Apr 6 14:34:58 2010 -0700 raw: fsync method is now required commit 55ab3a1ff843e3f0e24d2da44e71bffa5d853010 upstream. Commit 148f948ba877f4d3cdef036b1ff6d9f68986706a (vfs: Introduce new helpers for syncing after writing to O_SYNC file or IS_SYNC inode) broke the raw driver. We now call through generic_file_aio_write -> generic_write_sync -> vfs_fsync_range. vfs_fsync_range has: if (!fop || !fop->fsync) { ret = -EINVAL; goto out; } But drivers/char/raw.c doesn't set an fsync method. We have two options: fix it or remove the raw driver completely. I'm happy to do either, the fact this has been broken for so long suggests it is rarely used. The patch below adds an fsync method to the raw driver. My knowledge of the block layer is pretty sketchy so this could do with a once over. If we instead decide to remove the raw driver, this patch might still be useful as a backport to 2.6.33 and 2.6.32. Signed-off-by: Anton Blanchard Reviewed-by: Jan Kara Cc: Christoph Hellwig Cc: Alexander Viro Cc: Jens Axboe Reviewed-by: Jeff Moyer Tested-by: Jeff Moyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6e313203f4198d3bae98045cbb52d233a9b05e40 Author: Jiri Kosina Date: Tue Mar 23 16:32:37 2010 +0100 HID: fix oops in gyration_event() commit d8e4ebf8b603bdcd091540e6b5bddf0dec10d516 upstream. Fix oops caused by dereferencing field->hidinput in cases where the device hasn't been claimed by hid-input. Reported-by: Andreas Demmer Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4e44a798002732f3464e31adfb0276a41146278b Author: Alan Cox Date: Mon Nov 30 13:23:05 2009 +0000 pata_ali: Fix regression with old devices commit d6250a03fa736c1bff4df4601f5af2dc21f2bf9e upstream. Making the new stuff work broke some of the old chipsets. We need to go back to the old set up values for these it seems. Unfortunately even with documentation this is basically a mix of cargoculting and guesswork. Chased down to the exact line by Gianluca. Signed-off-by: Alan Cox Signed-off-by: Jeff Garzik Cc: Christoph Biedl Signed-off-by: Greg Kroah-Hartman commit 6807699cad68ecb224d2752cb5b2e760e8552e62 Author: Éric Piel Date: Mon Dec 14 18:01:40 2009 -0800 lis3: fix show rate for 8 bits chips commit 4b5d95b3809bcd77599122494aa3f575cd6ab1b9 upstream. Originally the driver was only targeted to 12bits sensors. When support for 8bits sensors was added, some slight difference in the registers were overlooked. This should fix it, both for initialization, and for displaying the rate. Reported-by: Kalhan Trisal Reported-by: Christoph Plattner Tested-by: Christoph Plattner Tested-by: Samu Onkalo Signed-off-by: Éric Piel Signed-off-by: Samu Onkalo Cc: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e2278e63b10b17980dcbc01e24fe0619f4b38bfd Author: Oleg Nesterov Date: Fri Apr 2 18:05:12 2010 +0200 tty: release_one_tty() forgets to put pids commit 6da8d866d0d39e9509ff826660f6a86a6757c966 upstream. release_one_tty(tty) can be called when tty still has a reference to pgrp/session. In this case we leak the pid. Signed-off-by: Oleg Nesterov Reported-by: Catalin Marinas Reported-and-tested-by: Tetsuo Handa Acked-by: Linus Torvalds Acked-by: Eric W. Biederman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fae08fb3f91a4e2e1034a89e0504a778bb5a4634 Author: Thomas Gleixner Date: Wed Mar 31 13:30:19 2010 +0200 genirq: Force MSI irq handlers to run with interrupts disabled commit 753649dbc49345a73a2454c770a3f2d54d11aec6 upstream. Network folks reported that directing all MSI-X vectors of their multi queue NICs to a single core can cause interrupt stack overflows when enough interrupts fire at the same time. This is caused by the fact that we run interrupt handlers by default with interrupts enabled unless the driver reuqests the interrupt with the IRQF_DISABLED set. The NIC handlers do not set this flag, so simultaneous interrupts can nest unlimited and cause the stack overflow. The only safe counter measure is to run the interrupt handlers with interrupts disabled. We can't switch to this mode in general right now, but it is safe to do so for MSI interrupts. Force IRQF_DISABLED for MSI interrupt handlers. Signed-off-by: Thomas Gleixner Cc: Andi Kleen Cc: Linus Torvalds Cc: Andrew Morton Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Alan Cox Cc: David Miller Cc: Greg Kroah-Hartman Cc: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit e3abceb77922fb9c6041b0925f97a9afa062513b Author: Seth Heasley Date: Thu Mar 25 16:14:41 2010 -0700 WATCHDOG: iTCO_wdt: TCO Watchdog patch for additional Intel Cougar Point DeviceIDs commit 4c7d849204341dea19be941a3c1eb4bdffac9cc4 upstream. This patch adds the Intel Cougar Point PCH LPC Controller DeviceIDs for iTCO Watchdog. Signed-off-by: Seth Heasley Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 628f1a0323b530051adabf7d3c52ad367176959e Author: Thomas Mingarelli Date: Wed Mar 17 15:33:31 2010 +0000 WATCHDOG: hpwdt - fix lower timeout limit commit 8ba42bd88c6982fe224b09c33151c797b0fdf1a5 upstream. [Novell Bug 581103] HP Watchdog driver has arbitrary (wrong) timeout limits. Fix the lower timeout limit to a more appropriate value. Signed-off-by: Thomas Mingarelli Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit a850f39d86b2fa5a0933ccd6c8e91e9e86d62937 Author: Wey-Yi Guy Date: Wed Feb 3 09:28:55 2010 -0800 mac80211: tear down all agg queues when restart/reconfig hw commit 74e2bd1fa3ae9695af566ad5a7a288898787b909 upstream. When there is a need to restart/reconfig hw, tear down all the aggregation queues and let the mac80211 and driver get in-sync to have the opportunity to re-establish the aggregation queues again. Need to wait until driver re-establish all the station information before tear down the aggregation queues, driver(at least iwlwifi driver) will reject the stop aggregation queue request if station is not ready. But also need to make sure the aggregation queues are tear down before waking up the queues, so mac80211 will not sending frames with aggregation bit set. Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6a45694284d21a5f1f322eea978247edd8916410 Author: Johannes Berg Date: Mon Mar 22 13:42:43 2010 -0700 mac80211: move netdev queue enabling to correct spot commit 7236fe29fd72d17074574ba312e7f1bb9d10abaa upstream. "mac80211: fix skb buffering issue" still left a race between enabling the hardware queues and the virtual interface queues. In hindsight it's totally obvious that enabling the netdev queues for a hardware queue when the hardware queue is enabled is wrong, because it could well possible that we can fill the hw queue with packets we already have pending. Thus, we must only enable the netdev queues once all the pending packets have been processed and sent off to the device. In testing, I haven't been able to trigger this race condition, but it's clearly there, possibly only when aggregation is being enabled. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c7f02946f8a70d815f2c37e88c3dde335d36417c Author: Valentin Longchamp Date: Fri Mar 26 11:44:33 2010 +0100 setup correct int pipe type in ar9170_usb_exec_cmd commit 2d20c72c021d96f8b9230396c8e3782f204214ec upstream. An int urb is constructed but we fill it in with a bulk pipe type. Commit f661c6f8c67bd55e93348f160d590ff9edf08904 implemented a pipe type check when CONFIG_USB_DEBUG is enabled. The check failed for all the ar9170 usb transfers and the driver could not configure the wifi dongle. This went unnoticed until now because most people don't have CONFIG_USB_DEBUG enabled. Signed-off-by: Valentin Longchamp Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit a2266949a5aa747f53ecfbe0c6836b8317794f91 Author: Dan Carpenter Date: Sun Mar 28 14:55:00 2010 +0300 iwlwifi: range checking issue commit 8e1a53c615e8efe0fac670f2973da64758748a8a upstream. IWL_RATE_COUNT is 13 and IWL_RATE_COUNT_LEGACY is 12. IWL_RATE_COUNT_LEGACY is the right one here because iwl3945_rates doesn't support 60M and also that's how "rates" is defined in iwlcore_init_geos() from drivers/net/wireless/iwlwifi/iwl-core.c. rates = kzalloc((sizeof(struct ieee80211_rate) * IWL_RATE_COUNT_LEGACY), GFP_KERNEL); Signed-off-by: Dan Carpenter Acked-by: Zhu Yi Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 79ae3ed1457827cf19ff1eab473d181a6156ff2f Author: Stanislaw Gruszka Date: Thu Mar 18 14:29:33 2010 +0000 iwlwifi: fix nfreed-- During backporting of a120e912eb51e347f36c71b60a1d13af74d30e83 ("iwlwifi: sanity check before counting number of tfds can be free") we forget one hunk, what make lot of messages "free more than tfds_in_queue" show up in dmesg. Signed-off-by: Stanislaw Gruszka Tested-by: Adel Gadllah (picked from https://patchwork.kernel.org/patch/86722/) Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit e69f8f53037556764c9c51821e75b72cc8f392d7 Author: Wey-Yi Guy Date: Thu Mar 18 09:05:00 2010 -0700 iwlwifi: counting number of tfds can be free for 4965 commit be6b38bcb175613f239e0b302607db346472c6b6 upstream. Forget one hunk in 4965 during "iwlwifi: error checking for number of tfds in queue" patch. Reported-by: Shanyu Zhao Signed-off-by: Wey-Yi Guy Signed-off-by: Reinette Chatre Signed-off-by: Greg Kroah-Hartman commit a0223a1cdb8c041d5700d28ab4507c8985aae380 Author: Matt Helsley Date: Fri Mar 26 23:51:44 2010 +0100 Freezer: Fix buggy resume test for tasks frozen with cgroup freezer commit 5a7aadfe2fcb0f69e2acc1fbefe22a096e792fc9 upstream. When the cgroup freezer is used to freeze tasks we do not want to thaw those tasks during resume. Currently we test the cgroup freezer state of the resuming tasks to see if the cgroup is FROZEN. If so then we don't thaw the task. However, the FREEZING state also indicates that the task should remain frozen. This also avoids a problem pointed out by Oren Ladaan: the freezer state transition from FREEZING to FROZEN is updated lazily when userspace reads or writes the freezer.state file in the cgroup filesystem. This means that resume will thaw tasks in cgroups which should be in the FROZEN state if there is no read/write of the freezer.state file to trigger this transition before suspend. NOTE: Another "simple" solution would be to always update the cgroup freezer state during resume. However it's a bad choice for several reasons: Updating the cgroup freezer state is somewhat expensive because it requires walking all the tasks in the cgroup and checking if they are each frozen. Worse, this could easily make resume run in N^2 time where N is the number of tasks in the cgroup. Finally, updating the freezer state from this code path requires trickier locking because of the way locks must be ordered. Instead of updating the freezer state we rely on the fact that lazy updates only manage the transition from FREEZING to FROZEN. We know that a cgroup with the FREEZING state may actually be FROZEN so test for that state too. This makes sense in the resume path even for partially-frozen cgroups -- those that really are FREEZING but not FROZEN. Reported-by: Oren Ladaan Signed-off-by: Matt Helsley Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d3ce482f41952fd74c53dcb23f89ae1b7ef29360 Author: Mike Christie Date: Tue Mar 9 14:14:51 2010 -0600 libiscsi: Fix recovery slowdown regression commit 4ae0a6c15efcc37e94e3f30e3533bdec03c53126 upstream. We could be failing/stopping a connection due to libiscsi starting recovery/cleanup, but the xmit path or scsi eh thread path could be dropping the connection at the same time. As a result the session->state gets set to failed instead of in recovery. We end up not blocking the session and so the replacement timeout never gets started and we only end up failing the IO when scsi_softirq_done sees that the cmd has been running for (cmd->allowed + 1) * rq->timeout secs. We used to fail the IO right away so users are seeing a long delay when using dm-multipath. This problem was added in 2.6.28. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit bbe04b45ff69b35fa2faf4306823a988f521a7b2 Author: Andrew Stubbs Date: Mon Mar 29 12:04:19 2010 +0900 sh: Fix FDPIC binary loader commit d5ab780305bb6d60a7b5a74f18cf84eb6ad153b1 upstream. Ensure that the aux table is properly initialized, even when optional features are missing. Without this, the FDPIC loader did not work. Signed-off-by: Andrew Stubbs Signed-off-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 69fd993218cadae95f8315ce2ba2df2826f7475f Author: Matt Fleming Date: Sun Mar 28 20:08:25 2010 +0000 sh: Enable the mmu in start_secondary() commit 4bea3418c737891894b9d3d3e9f8bbd67d66fa38 upstream. For the boot, enable_mmu() is called from setup_arch() but we don't call setup_arch() for any of the other cpus. So turn on the non-boot cpu's mmu inside of start_secondary(). I noticed this bug on an SMP board when trying to map I/O memory (smsc911x registers) into the kernel address space. Since the Address Translation bit in MMUCR wasn't set, accessing the virtual address where the smsc911x registers were supposedly mapped actually performed a physical address access. Signed-off-by: Matt Fleming Signed-off-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 94aa7e9130a50f65acad20f67a872058001361b3 Author: Christoph Hellwig Date: Fri Mar 12 09:42:17 2010 +1100 xfs: fix locking for inode cache radix tree tag updates commit f1f724e4b523d444c5a598d74505aefa3d6844d2 upstream The radix-tree code requires it's users to serialize tag updates against other updates to the tree. While XFS protects tag updates against each other it does not serialize them against updates of the tree contents, which can lead to tag corruption. Fix the inode cache to always take pag_ici_lock in exclusive mode when updating radix tree tags. Signed-off-by: Christoph Hellwig Reported-by: Patrick Schreurs Tested-by: Patrick Schreurs Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit e52af5078f958b84f5ca2f06f692f96438d82d84 Author: Dave Chinner Date: Fri Mar 12 09:42:16 2010 +1100 xfs: Non-blocking inode locking in IO completion commit 77d7a0c2eeb285c9069e15396703d0cb9690ac50 upstream The introduction of barriers to loop devices has created a new IO order completion dependency that XFS does not handle. The loop device implements barriers using fsync and so turns a log IO in the XFS filesystem on the loop device into a data IO in the backing filesystem. That is, the completion of log IOs in the loop filesystem are now dependent on completion of data IO in the backing filesystem. This can cause deadlocks when a flush daemon issues a log force with an inode locked because the IO completion of IO on the inode is blocked by the inode lock. This in turn prevents further data IO completion from occuring on all XFS filesystems on that CPU (due to the shared nature of the completion queues). This then prevents the log IO from completing because the log is waiting for data IO completion as well. The fix for this new completion order dependency issue is to make the IO completion inode locking non-blocking. If the inode lock can't be grabbed, simply requeue the IO completion back to the work queue so that it can be processed later. This prevents the completion queue from being blocked and allows data IO completion on other inodes to proceed, hence avoiding completion order dependent deadlocks. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 76962b5ed721dd91bd736c65944522798a35ced5 Author: Christoph Hellwig Date: Fri Mar 12 09:42:15 2010 +1100 xfs: remove invalid barrier optimization from xfs_fsync commit e8b217e7530c6a073ac69f1c85b922d93fdf5647 upstream Date: Tue, 2 Feb 2010 10:16:26 +1100 We always need to flush the disk write cache and can't skip it just because the no inode attributes have changed. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 83b546b83752bd43cfc26458709d48293956a3c8 Author: Dave Chinner Date: Fri Mar 12 09:42:14 2010 +1100 xfs: don't hold onto reserved blocks on remount, ro commit cbe132a8bdcff0f9afd9060948fb50597c7400b8 upstream If we hold onto reserved blocks when doing a remount,ro we end up writing the blocks used count to disk that includes the reserved blocks. Reserved blocks are not actually used, so this results in the values in the superblock being incorrect. Hence if we run xfs_check or xfs_repair -n while the filesystem is mounted remount,ro we end up with an inconsistent filesystem being reported. Also, running xfs_copy on the remount,ro filesystem will result in an inconsistent image being generated. To fix this, unreserve the blocks when doing the remount,ro, and reserved them again on remount,rw. This way a remount,ro filesystem will appear consistent on disk to all utilities. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 1b8e6dfb4997f2950cf6720f5b7a434a04ee80f0 Author: Christoph Hellwig Date: Fri Mar 12 09:42:13 2010 +1100 xfs: quota limit statvfs available blocks commit 9b00f30762fe9f914eb6e03057a616ed63a4e8ca upstream A "df" run on an NFS client of an exported XFS file system reports the wrong information for "available" blocks. When a block quota is enforced, the amount reported as free is limited by the quota, but the amount reported available is not (and should be). Reported-by: Guk-Bong, Kwon Signed-off-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 059f754c44af50340f8921df60091254b0bfb1e6 Author: Dave Chinner Date: Fri Mar 12 09:42:12 2010 +1100 xfs: xfs_swap_extents needs to handle dynamic fork offsets commit e09f98606dcc156de1146c209d45a0d6d5f51c3f upstream When swapping extents, we can corrupt inodes by swapping data forks that are in incompatible formats. This is caused by the two indoes having different fork offsets due to the presence of an attribute fork on an attr2 filesystem. xfs_fsr tries to be smart about setting the fork offset, but the trick it plays only works on attr1 (old fixed format attribute fork) filesystems. Changing the way xfs_fsr sets up the attribute fork will prevent this situation from ever occurring, so in the kernel code we can get by with a preventative fix - check that the data fork in the defragmented inode is in a format valid for the inode it is being swapped into. This will lead to files that will silently and potentially repeatedly fail defragmentation, so issue a warning to the log when this particular failure occurs to let us know that xfs_fsr needs updating/fixing. To help identify how to improve xfs_fsr to avoid this issue, add trace points for the inodes being swapped so that we can determine why the swap was rejected and to confirm that the code is making the right decisions and modifications when swapping forks. A further complication is even when the swap is allowed to proceed when the fork offset is different between the two inodes then value for the maximum number of extents the data fork can hold can be wrong. Make sure these are also set correctly after the swap occurs. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit bcb56a66459dafdc87b48d2e84cbd73eb4fbc385 Author: Dave Chinner Date: Fri Mar 12 09:42:11 2010 +1100 xfs: fix stale inode flush avoidance commit 4b6a46882cca8349e8942e2650c33b11bc571c92 upstream When reclaiming stale inodes, we need to guarantee that inodes are unpinned before returning with a "clean" status. If we don't we can reclaim inodes that are pinned, leading to use after free in the transaction subsystem as transactions complete. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 9e1e9675fb29c0e94a7c87146138aa2135feba2f Author: Dave Chinner Date: Fri Mar 12 09:42:10 2010 +1100 xfs: reclaim all inodes by background tree walks commit 57817c68229984818fea9e614d6f95249c3fb098 upstream We cannot do direct inode reclaim without taking the flush lock to ensure that we do not reclaim an inode under IO. We check the inode is clean before doing direct reclaim, but this is not good enough because the inode flush code marks the inode clean once it has copied the in-core dirty state to the backing buffer. It is the flush lock that determines whether the inode is still under IO, even though it is marked clean, and the inode is still required at IO completion so we can't reclaim it even though it is clean in core. Hence the requirement that we need to take the flush lock even on clean inodes because this guarantees that the inode writeback IO has completed and it is safe to reclaim the inode. With delayed write inode flushing, we could end up waiting a long time on the flush lock even for a clean inode. The background reclaim already handles this efficiently, so avoid all the problems by killing the direct reclaim path altogether. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 22a482c6215ed335d2de07aa113d3cd317015cf7 Author: Dave Chinner Date: Fri Mar 12 09:42:09 2010 +1100 xfs: Avoid inodes in reclaim when flushing from inode cache commit 018027be90a6946e8cf3f9b17b5582384f7ed117 upstream The reclaim code will handle flushing of dirty inodes before reclaim occurs, so avoid them when determining whether an inode is a candidate for flushing to disk when walking the radix trees. This is based on a test patch from Christoph Hellwig. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 96ce91ba515e97ef6996f5847d3bcc46ed647385 Author: Dave Chinner Date: Fri Mar 12 09:42:08 2010 +1100 xfs: reclaim inodes under a write lock commit c8e20be020f234c8d492927a424a7d8bbefd5b5d upstream Make the inode tree reclaim walk exclusive to avoid races with concurrent sync walkers and lookups. This is a version of a patch posted by Christoph Hellwig that avoids all the code duplication. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 74a1282e07bc9e4163447e79cb1da56d521aab51 Author: Dave Chinner Date: Fri Mar 12 09:42:07 2010 +1100 xfs: Ensure we force all busy extents in range to disk commit fd45e4784164d1017521086524e3442318c67370 upstream When we search for and find a busy extent during allocation we force the log out to ensure the extent free transaction is on disk before the allocation transaction. The current implementation has a subtle bug in it--it does not handle multiple overlapping ranges. That is, if we free lots of little extents into a single contiguous extent, then allocate the contiguous extent, the busy search code stops searching at the first extent it finds that overlaps the allocated range. It then uses the commit LSN of the transaction to force the log out to. Unfortunately, the other busy ranges might have more recent commit LSNs than the first busy extent that is found, and this results in xfs_alloc_search_busy() returning before all the extent free transactions are on disk for the range being allocated. This can lead to potential metadata corruption or stale data exposure after a crash because log replay won't replay all the extent free transactions that cover the allocation range. Modified-by: Alex Elder (Dropped the "found" argument from the xfs_alloc_busysearch trace event.) Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit d4203bda8967c87982eaf3f39472f1e64aa07184 Author: Dave Chinner Date: Fri Mar 12 09:42:06 2010 +1100 xfs: Don't flush stale inodes commit 44e08c45cc14e6190a424be8d450070c8e508fad upstream Because inodes remain in cache much longer than inode buffers do under memory pressure, we can get the situation where we have stale, dirty inodes being reclaimed but the backing storage has been freed. Hence we should never, ever flush XFS_ISTALE inodes to disk as there is no guarantee that the backing buffer is in cache and still marked stale when the flush occurs. Signed-off-by: Dave Chinner Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 8ae95bb9072d9a2a4bb5ccac932489e03c5398ff Author: Christoph Hellwig Date: Fri Mar 12 09:42:05 2010 +1100 xfs: fix timestamp handling in xfs_setattr commit d6d59bada372bcf8bd36c3bbc71c485c29dd2a4b upstream We currently have some rather odd code in xfs_setattr for updating the a/c/mtime timestamps: - first we do a non-transaction update if all three are updated together - second we implicitly update the ctime for various changes instead of relying on the ATTR_CTIME flag - third we set the timestamps to the current time instead of the arguments in the iattr structure in many cases. This patch makes sure we update it in a consistent way: - always transactional - ctime is only updated if ATTR_CTIME is set or we do a size update, which is a special case - always to the times passed in from the caller instead of the current time The only non-size caller of xfs_setattr that doesn't come from the VFS is updated to set ATTR_CTIME and pass in a valid ctime value. Reported-by: Eric Blake Signed-off-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 55f45642032bebb04d56e41b33122de5449cb41d Author: Christoph Hellwig Date: Fri Mar 12 09:42:04 2010 +1100 xfs: check for not fully initialized inodes in xfs_ireclaim commit b44b1126279b60597f96bbe77507b1650f88a969 upstream Add an assert for inodes not added to the inode cache in xfs_ireclaim, to make sure we're not going to introduce something like the famous nfsd inode cache bug again. Signed-off-by: Christoph Hellwig Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit b3e6e64f48177a32c07364e4c699ae4db0ff7807 Author: Jason Gunthorpe Date: Fri Mar 12 09:42:03 2010 +1100 xfs: Fix error return for fallocate() on XFS commit 44a743f68705c681439f264deb05f8f38e9048d3 upstream Noticed that through glibc fallocate would return 28 rather than -1 and errno = 28 for ENOSPC. The xfs routines uses XFS_ERROR format positive return error codes while the syscalls use negative return codes. Fixup the two cases in xfs_vn_fallocate syscall to convert to negative. Signed-off-by: Jason Gunthorpe Reviewed-by: Eric Sandeen Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit ce49b28e33e5d526e77fca788658f1d97c29a528 Author: Andy Poling Date: Fri Mar 12 09:42:02 2010 +1100 xfs: Wrapped journal record corruption on read at recovery commit fc5bc4c85c45f0bf854404e5736aa8b65720a18d upstream Summary of problem: If a journal record wraps at the physical end of the journal, it has to be read in two parts in xlog_do_recovery_pass(): a read at the physical end and a read at the physical beginning. If xlog_bread() has to re-align the first read, the second read request does not take that re-alignment into account. If the first read was re-aligned, the second read over-writes the end of the data from the first read, effectively corrupting it. This can happen either when reading the record header or reading the record data. The first sanity check in xlog_recover_process_data() is to check for a valid clientid, so that is the error reported. Summary of fix: If there was a first read at the physical end, XFS_BUF_PTR() returns where the data was requested to begin. Conversely, because it is the result of xlog_align(), offset indicates where the requested data for the first read actually begins - whether or not xlog_bread() has re-aligned it. Using offset as the base for the calculation of where to place the second read data ensures that it will be correctly placed immediately following the data from the first read instead of sometimes over-writing the end of it. The attached patch has resolved the reported problem of occasional inability to recover the journal (reporting "bad clientid"). Signed-off-by: Andy Poling Reviewed-by: Alex Elder Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit fe5bdcac7218003c151a8b4d837c2e6632c81a07 Author: Christoph Hellwig Date: Fri Mar 12 09:42:01 2010 +1100 xfs: I/O completion handlers must use NOFS allocations commit 80641dc66a2d6dfb22af4413227a92b8ab84c7bb upstream When completing I/O requests we must not allow the memory allocator to recurse into the filesystem, as we might deadlock on waiting for the I/O completion otherwise. The only thing currently allocating normal GFP_KERNEL memory is the allocation of the transaction structure for the unwritten extent conversion. Add a memflags argument to _xfs_trans_alloc to allow controlling the allocator behaviour. Signed-off-by: Christoph Hellwig Reported-by: Thomas Neumann Tested-by: Thomas Neumann Reviewed-by: Alex Elder Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit b1d0040c6ec4b45cdcf5a4d788c50e58b7c0b20e Author: Christoph Hellwig Date: Fri Mar 12 09:42:00 2010 +1100 xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks commit c56c9631cbe88f08854a56ff9776c1f310916830 upstream When xfs_free_eofblocks is called from ->release the VM might already hold the mmap_sem, but in the write path we take the iolock before taking the mmap_sem in the generic write code. Switch xfs_free_eofblocks to only trylock the iolock if called from ->release and skip trimming the prellocated blocks in that case. We'll still free them later on the final iput. Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit f2a111377a25d43ce14212ed616e1e7f6bf31488 Author: Christoph Hellwig Date: Fri Mar 12 09:41:59 2010 +1100 xfs: simplify inode teardown commit 848ce8f731aed0a2d4ab5884a4f6664af73d2dd0 upstream Currently the reclaim code for the case where we don't reclaim the final reclaim is overly complicated. We know that the inode is clean but instead of just directly reclaiming the clean inode we go through the whole process of marking the inode reclaimable just to directly reclaim it from the calling context. Besides being overly complicated this introduces a race where iget could recycle an inode between marked reclaimable and actually being reclaimed leading to panics. This patch gets rid of the existing reclaim path, and replaces it with a simple call to xfs_ireclaim if the inode was clean. While we're at it we also use the slightly more lax xfs_inode_clean check we'd use later to determine if we need to flush the inode here. Finally get rid of xfs_reclaim function and place the remaining small bits of reclaim code directly into xfs_fs_destroy_inode. Signed-off-by: Christoph Hellwig Reported-by: Patrick Schreurs Reported-by: Tommy van Leeuwen Tested-by: Patrick Schreurs Reviewed-by: Alex Elder Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 409fab53edf73b237f684adaf50d2594d4bc66a9 Author: Chris Wilson Date: Thu Mar 18 11:56:54 2010 +0000 drm: Return ENODEV if the inode mapping changes commit da58405860b992d2bb21ebae5d685fe3204dd3f0 upstream. Replace a BUG_ON with an error code in the event that the inode mapping changes between calls to drm_open. This may happen for instance if udev is loaded subsequent to the original opening of the device: [ 644.291870] kernel BUG at drivers/gpu/drm/drm_fops.c:146! [ 644.291876] invalid opcode: 0000 [#1] SMP [ 644.291882] last sysfs file: /sys/kernel/uevent_seqnum [ 644.291888] [ 644.291895] Pid: 7276, comm: lt-cairo-test-s Not tainted 2.6.34-rc1 #2 N150/N210/N220 /N150/N210/N220 [ 644.291903] EIP: 0060:[] EFLAGS: 00210283 CPU: 0 [ 644.291912] EIP is at drm_open+0x4b1/0x4e2 [ 644.291918] EAX: f72d8d18 EBX: f790a400 ECX: f73176b8 EDX: 00000000 [ 644.291923] ESI: f790a414 EDI: f790a414 EBP: f647ae20 ESP: f647adfc [ 644.291929] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 644.291937] Process lt-cairo-test-s (pid: 7276, ti=f647a000 task=f73f5c80 task.ti=f647a000) [ 644.291941] Stack: [ 644.291945] 00000000 f7bb7400 00000080 f6451100 f73176b8 f6479214 f6451100 f73176b8 [ 644.291957] <0> c1297ce0 f647ae34 c11c6c04 f73176b8 f7949800 00000000 f647ae54 c1080ac5 [ 644.291969] <0> f7949800 f6451100 00000000 f6451100 f73176b8 f6452780 f647ae70 c107d1e6 [ 644.291982] Call Trace: [ 644.291991] [] ? drm_stub_open+0x8a/0xb8 [ 644.292000] [] ? chrdev_open+0xef/0x106 [ 644.292008] [] ? __dentry_open+0xd4/0x1a6 [ 644.292015] [] ? nameidata_to_filp+0x31/0x45 [ 644.292022] [] ? chrdev_open+0x0/0x106 [ 644.292030] [] ? do_last+0x346/0x423 [ 644.292037] [] ? do_filp_open+0x190/0x415 [ 644.292046] [] ? handle_mm_fault+0x214/0x710 [ 644.292053] [] ? do_sys_open+0x4d/0xe9 [ 644.292061] [] ? do_page_fault+0x211/0x23f [ 644.292068] [] ? sys_open+0x23/0x2b [ 644.292075] [] ? sysenter_do_call+0x12/0x26 [ 644.292079] Code: 89 f0 89 55 dc e8 8d 96 0a 00 8b 45 e0 8b 55 dc 83 78 04 01 75 28 8b 83 18 02 00 00 85 c0 74 0f 8b 4d ec 3b 81 ac 00 00 00 74 13 <0f> 0b eb fe 8b 4d ec 8b 81 ac 00 00 00 89 83 18 02 00 00 89 f0 [ 644.292143] EIP: [] drm_open+0x4b1/0x4e2 SS:ESP 0068:f647adfc [ 644.292175] ---[ end trace 2ddd476af89a60fa ]--- Signed-off-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 94f6b5578f95a12b02b89db29854eb77995199e9 Author: Alex Deucher Date: Wed Mar 10 18:33:03 2010 -0500 drm/radeon/kms: fix pal tv-out support on legacy IGP chips commit 15f7207761cfcf8f53fb6e5cacffe060478782c3 upstream. Based on ddx patch by Andrzej Hajda. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 1d00cd4e5294606417893ceab6a357052d92159a Author: Dave Airlie Date: Fri Mar 19 10:33:44 2010 +1000 drm/radeon/kms: don't print error on -ERESTARTSYS. commit 97f23b3d85a4d734a8584dade3a34579931c8f8d upstream. We can get this if the user moves the mouse when we are waiting to move some stuff around in the validate. Don't fail. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e72f38d31b4a9a5e6c6207a815067be361e4b872 Author: Oleg Nesterov Date: Thu Apr 1 15:13:57 2010 +0200 oom: fix the unsafe usage of badness() in proc_oom_score() commit b95c35e76b29ba812e5dabdd91592e25ec640e93 upstream. proc_oom_score(task) has a reference to task_struct, but that is all. If this task was already released before we take tasklist_lock - we can't use task->group_leader, it points to nowhere - it is not safe to call badness() even if this task is ->group_leader, has_intersects_mems_allowed() assumes it is safe to iterate over ->thread_group list. - even worse, badness() can hit ->signal == NULL Add the pid_alive() check to ensure __unhash_process() was not called. Also, use "task" instead of task->group_leader. badness() should return the same result for any sub-thread. Currently this is not true, but this should be changed anyway. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 46049d384052f69e86855b5cb9948124a35d9a96 Author: Nikolaus Schulz Date: Thu Apr 1 02:21:10 2010 +0900 fat: fix buffer overflow in vfat_create_shortname() commit 30d1872d9eb3663b4cf7bdebcbf5cd465674cced upstream. When using the string representation of a random counter as part of the base name, ensure that it is no longer than 4 bytes. Since we are repeatedly decrementing the counter in a loop until we have found a unique base name, the counter may wrap around zero; therefore, it is not enough to mask its higher bits before entering the loop, this must be done inside the loop. [hirofumi@mail.parknet.co.jp: use snprintf()] Signed-off-by: Nikolaus Schulz Signed-off-by: OGAWA Hirofumi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aa35ec771b41f9803e14e4623540cb1b38fbbe2c Author: Zhao Yakui Date: Thu Mar 4 08:25:55 2010 +0000 drm: remove the EDID blob stored in the EDID property when it is disconnected commit 725398322d05486109375fbb85c3404108881e17 upstream. Now the EDID property will be updated when the corresponding EDID can be obtained from the external display device. But after the external device is plugged-out, the EDID property is not updated. In such case we still get the corresponding EDID property although it is already detected as disconnected. https://bugs.freedesktop.org/show_bug.cgi?id=26743 Signed-off-by: Zhao Yakui Signed-off-by: Zhenyu Wang Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit b46992af7d9c0841034d3b9eea8de673affdcb6e Author: Alex Deucher Date: Wed Mar 3 13:39:13 2010 -0500 drm/radeon: add new RS880 pci id commit 338e2b1d571e4873908b199c90d6a31f65137fe3 upstream. This should go to 2.6.33 stable as well. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2c3f0d85a4db34ad09c7bda60a1a28928ead9d38 Author: Ben Skeggs Date: Thu Feb 18 09:12:09 2010 +1000 drm/edid: allow certain bogus edids to hit a fixup path rather than fail commit 44fef22416886a04d432043f741a6faf2c6ffefd upstream. Signed-off-by: Ben Skeggs Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman