summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2009-05-08tracing: x86, mmiotrace: fix range testStuart Bennett
commit 33015c85995716d03f6293346cf05a1908b0fb9a upstream. Matching on (addr == (p->addr + p->len)) causes problems when mappings are adjacent. [ Impact: fix mmiotrace confusion on adjacent iomaps ] Signed-off-by: Stuart Bennett <stuart@freedesktop.org> Acked-by: Pekka Paalanen <pq@iki.fi> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08powerpc: Sanitize stack pointer in signal handling codeJosh Boyer
This has been backported to 2.6.29.x from commit efbda86098 in Linus' tree On powerpc64 machines running 32-bit userspace, we can get garbage bits in the stack pointer passed into the kernel. Most places handle this correctly, but the signal handling code uses the passed value directly for allocating signal stack frames. This fixes the issue by introducing a get_clean_sp function that returns a sanitized stack pointer. For 32-bit tasks on a 64-bit kernel, the stack pointer is masked correctly. In all other cases, the stack pointer is simply returned. Additionally, we pass an 'is_32' parameter to get_sigframe now in order to get the properly sanitized stack. The callers are know to be 32 or 64-bit statically. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08x86/PCI: don't call e820_all_mapped with -1 in the mmconfig caseYinghai Lu
commit 044cd80942e47b9de0915b627902adf05c52377f upstream. e820_all_mapped need end is (addr + size) instead of (addr + size - 1) Cc: stable@kernel.org Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08x86-64: fix FPU corruption with signals and preemptionSuresh Siddha
commit 06c38d5e36b12d040839ff224e805146c0368556 upstream. In 64bit signal delivery path, clear_used_math() was happening before saving the current active FPU state on to the user stack for signal handling. Between clear_used_math() and the state store on to the user stack, potentially we can get a page fault for the user address and can block. Infact, while testing we were hitting the might_fault() in __clear_user() which can do a schedule(). At a later point in time, we will schedule back into this process and resume the save state (using "xsave/fxsave" instruction) which can lead to DNA fault. And as used_math was cleared before, we will reinit the FP state in the DNA fault and continue. This reinit will result in loosing the FPU state of the process. Move clear_used_math() to a point after the FPU state has been stored onto the user stack. This issue is present from a long time (even before the xsave changes and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x series because of the __clear_user() in this path, which has an explicit __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY. [ Impact: fix FPU state corruption ] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08KVM: x86: release time_page on vcpu destructionJoerg Roedel
upstream commit: 7f1ea208968f021943d4103ba59e06bb6d8239cb Not releasing the time_page causes a leak of that page or the compound page it is situated in. Cc: stable@kernel.org Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08KVM: MMU: disable global page optimizationMarcelo Tosatti
upstream commit: bf47a760f66add7870fba33ab50f58b550d6bbd1 Complexity to fix it not worthwhile the gains, as discussed in http://article.gmane.org/gmane.comp.emulators.kvm.devel/28649. Cc: stable@kernel.org Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> [mtosatti: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27x86, PAT: Remove page granularity tracking for vm_insert_pfn mapsPallipadi, Venkatesh
upstream commit: 4b065046273afa01ec8e3de7da407e8d3599251d This change resolves the problem of too many single page entries in pat_memtype_list and "freeing invalid memtype" errors with i915, reported here: http://marc.info/?l=linux-kernel&m=123845244713183&w=2 Remove page level granularity track and untrack of vm_insert_pfn. memtype tracking at page granularity does not scale and cleaner approach would be for the driver to request a type for a bigger IO address range or PCI io memory range for that device, either at mmap time or driver init time and just use that type during vm_insert_pfn. This patch just removes the track/untrack of vm_insert_pfn. That means we will be in same state as 2.6.28, with respect to these APIs. Newer APIs for the drivers to request a memtype for a bigger region is coming soon. [ Impact: fix Xorg startup warnings and hangs ] Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Tested-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <20090408223716.GC3493@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27KVM: is_long_mode() should check for EFER.LMAAmit Shah
upstream commit: 41d6af119206e98764b4ae6d264d63acefcf851e is_long_mode currently checks the LongModeEnable bit in EFER instead of the LongModeActive bit. This is wrong, but we survived this till now since it wasn't triggered. This breaks guests that go from long mode to compatibility mode. This is noticed on a solaris guest and fixes bug #1842160 Signed-off-by: Amit Shah <amit.shah@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27KVM: VMX: Update necessary state when guest enters long modeAmit Shah
upstream commit: 401d10dee083bda281f2fdcdf654080313ba30ec setup_msrs() should be called when entering long mode to save the shadow state for the 64-bit guest state. Using vmx_set_efer() in enter_lmode() removes some duplicated code and also ensures we call setup_msrs(). We can safely pass the value of shadow_efer to vmx_set_efer() as no other bits in the efer change while enabling long mode (guest first sets EFER.LME, then sets CR0.PG which causes a vmexit where we activate long mode). With this fix, is_long_mode() can check for EFER.LMA set instead of EFER.LME and 5e23049e86dd298b72e206b420513dbc3a240cd9 can be reverted. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27KVM: Reset PIT irq injection logic when the PIT IRQ is unmaskedAvi Kivity
upstream commit: 4780c65904f0fc4e312ee2da9383eacbe04e61ea While the PIT is masked the guest cannot ack the irq, so the reinject logic will never allow the interrupt to be injected. Fix by resetting the reinjection counters on unmask. Unbreaks Xen. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27KVM: Add CONFIG_HAVE_KVM_IRQCHIPAvi Kivity
upstream commit: 5d9b8e30f543a9f21a968a4cda71e8f6d1c66a61 Two KVM archs support irqchips and two don't. Add a Kconfig item to make selecting between the two models easier. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27KVM: Fix missing smp tlb flush in invlpgAndrea Arcangeli
upstream commit: 4539b35881ae9664b0e2953438dd83f5ee02c0b4 When kvm emulates an invlpg instruction, it can drop a shadow pte, but leaves the guest tlbs intact. This can cause memory corruption when swapping out. Without this the other cpu can still write to a freed host physical page. tlb smp flush must happen if rmap_remove is called always before mmu_lock is released because the VM will take the mmu_lock before it can finally add the page to the freelist after swapout. mmu notifier makes it safe to flush the tlb after freeing the page (otherwise it would never be safe) so we can do a single flush for multiple sptes invalidated. Cc: stable@kernel.org Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> [mtosatti: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27x86: disable X86_PTRACE_BTS for nowIngo Molnar
upstream commit: d45b41ae8da0f54aec0eebcc6f893ba5f22a1e8e Oleg Nesterov found a couple of races in the ptrace-bts code and fixes are queued up for it but they did not get ready in time for the merge window. We'll merge them in v2.6.31 - until then mark the feature as CONFIG_BROKEN. There's no user-space yet making use of this so it's not a big issue. Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> [chrisw: trivial 2.6.29 backport] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27powerpc: Fix data-corrupting bug in __futex_atomic_opPaul Mackerras
upstream commit: 306a82881b14d950d59e0b59a55093a07d82aa9a Richard Henderson pointed out that the powerpc __futex_atomic_op has a bug: it will write the wrong value if the stwcx. fails and it has to retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten by the result from the first time around the loop. This happens because it uses the same register for 'oparg' (an input) as it uses for the result. This fixes it by using separate registers for 'oparg' and 'ret'. Cc: stable@kernel.org Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27x86: fix broken irq migration logic while cleaning up multiple vectorsSuresh Siddha
upstream commit: 68a8ca593fac82e336a792226272455901fa83df Impact: fix spurious IRQs During irq migration, we send a low priority interrupt to the previous irq destination. This happens in non interrupt-remapping case after interrupt starts arriving at new destination and in interrupt-remapping case after modifying and flushing the interrupt-remapping table entry caches. This low priority irq cleanup handler can cleanup multiple vectors, as multiple irq's can be migrated at almost the same time. While there will be multiple invocations of irq cleanup handler (one cleanup IPI for each irq migration), first invocation of the cleanup handler can potentially cleanup more than one vector (as the first invocation can see the requests for more than vector cleanup). When we cleanup multiple vectors during the first invocation of the smp_irq_move_cleanup_interrupt(), other vectors that are to be cleanedup can still be pending in the local cpu's IRR (as smp_irq_move_cleanup_interrupt() runs with interrupts disabled). When we are ready to unhook a vector corresponding to an irq, check if that vector is registered in the local cpu's IRR. If so skip that cleanup and do a self IPI with the cleanup vector, so that we give a chance to service the pending vector interrupt and then cleanup that vector allocation once we execute the lowest priority handler. This fixes spurious interrupts seen when migrating multiple vectors at the same time. [ This is apparently possible even on conventional xapic, although to the best of our knowledge it has never been seen. The stable maintainers may wish to consider this one for -stable. ] [suresh: backport to 2.6.29] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27sparc64: Fix bug in ("sparc64: Flush TLB before releasing pages.")David Miller
[ No upstream commit, this regression was added only to 2.6.29.1 ] Unfortunately I merged an earlier version of commit b6816b706138c3870f03115071872cad824f90b4 ("sparc64: Flush TLB before releasing pages.") than what I actually tested and merged upstream. Simply diffing asm/tlb_64.h in Linus's tree vs. what ended up in 2.6.29.1 confirms this. Sync things up to fix BUG() triggers some users are seeing. Reported-by: Dennis Gilmore <dennis@ausil.us> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27ACPI: cap off P-state transition latency from buggy BIOSesPallipadi, Venkatesh
upstream commit: a59d1637eb0e0a37ee0e5c92800c60abe3624e24 Some BIOSes report very high frequency transition latency which are plainly wrong on CPus that can change frequency using native MSR interface. One such system is IBM T42 (2327-8ZU) as reported by Owen Taylor and Rik van Riel. cpufreq_ondemand driver uses this transition latency to come up with a reasonable sampling interval to sample CPU usage and with such high latency value, ondemand sampling interval ends up being very high (0.5 sec, in this particular case), resulting in performance impact due to slow response to increasing frequency. Fix it by capping-off the transition latency to 20uS for native MSR based frequency transitions. mjg: We've confirmed that this also helps on the X31 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27x86, setup: mark %esi as clobbered in E820 BIOS callMichael K. Johnson
upstream commit: 01522df346f846906eaf6ca57148641476209909 Jordan Hargrave diagnosed a BIOS clobbering %esi in the E820 call. That particular BIOS has been fixed, but there is a possibility that this is responsible for other occasional reports of early boot failure, and it does not hurt to add %esi to the clobbers. -stable candidate patch. Cc: Justin Forbes <jmforbes@linuxtx.org> Signed-off-by: Michael K Johnson <johnsonm@rpath.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: stable@kernel.org Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27MIPS: Compat: Zero upper 32-bit of offset_high and offset_low.Ralf Baechle
upstream commit: d6c178e9694e7e0c7ffe0289cf4389a498cac735 Through sys_llseek() arguably should do exactly that it doesn't which means llseek(2) will fail for o32 processes if offset_low has bit 31 set. As suggested by Heiko Carstens. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27PCI/x86: detect host bridge config space size w/o using quirksYinghai Lu
upstream commit: dfadd9edff498d767008edc6b2a6e86a7a19934d Many host bridges support a 4k config space, so check them directy instead of using quirks to add them. We only need to do this extra check for host bridges at this point, because only host bridges are known to have extended address space without also having a PCI-X/PCI-E caps. Other devices with this property could be done with quirks (if there are any). As a bonus, we can remove the quirks for AMD host bridges with family 10h and 11h since they're not needed any more. With this patch, we can get correct pci cfg size of new Intel CPUs/IOHs with host bridges. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: H. Peter Anvin <hpa@zytor.com> Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Cc: <stable@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02sparc64: Fix reset hangs on Niagara systems.David S. Miller
[ Upstream commit ffaba674090f287afe0c44fd8d978c64c03581a8 ] Hypervisor versions older than version 1.6.1 cannot handle leaving the profile counter overflow interrupt chirping when the system does a soft reset. So use a reboot notifier to shut off the NMI watchdog. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02sparc64: Flush TLB before releasing pages.David S. Miller
[ Upstream commit a552a42cfa91ab653128dff89a70c8dde7fed042 ] tlb_flush_mmu() needs to flush pending TLB entries before processing the mmu_gather ->pages list. Noticed by Benjamin Herrenschmidt. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02sparc64: Fix MM refcount check in smp_flush_tlb_pending().David S. Miller
[ Upstream commit f9384d41c02408dd404aa64d66d0ef38adcf6479 ] As explained by Benjamin Herrenschmidt: > CPU 0 is running the context, task->mm == task->active_mm == your > context. The CPU is in userspace happily churning things. > > CPU 1 used to run it, not anymore, it's now running fancyfsd which > is a kernel thread, but current->active_mm still points to that > same context. > > Because there's only one "real" user, mm_users is 1 (but mm_count is > elevated, it's just that the presence on CPU 1 as active_mm has no > effect on mm_count(). > > At this point, fancyfsd decides to invalidate a mapping currently mapped > by that context, for example because a networked file has changed > remotely or something like that, using unmap_mapping_ranges(). > > So CPU 1 goes into the zapping code, which eventually ends up calling > flush_tlb_pending(). Your test will succeed, as current->active_mm is > indeed the target mm for the flush, and mm_users is indeed 1. So you > will -not- send an IPI to the other CPU, and CPU 0 will continue happily > accessing the pages that should have been unmapped. To fix this problem, check ->mm instead of ->active_mm, and this means: > So if you test current->mm, you effectively account for mm_users == 1, > so the only way the mm can be active on another processor is as a lazy > mm for a kernel thread. So your test should work properly as long > as you don't have a HW that will do speculative TLB reloads into the > TLB on that other CPU (and even if you do, you flush-on-switch-in should > get rid of any crap here). And therefore we should be OK. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02KVM: MMU: Fix another largepage memory leakJoerg Roedel
upstream commit: c5bc22424021cabda862727fb3f5098b866f074d In the paging_fetch function rmap_remove is called after setting a large pte to non-present. This causes rmap_remove to not drop the reference to the large page. The result is a memory leak of that page. Cc: stable@kernel.org Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Acked-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02lguest: wire up pte_update/pte_update_deferRusty Russell
upstream commit: b7ff99ea53cd16de8f6166c0e98f19a7c6ca67ee Impact: intermittent guest segv/crash fix I've been seeing random guest bad address crashes and segmentation faults: bisect led to 4f98a2fee8 (vmscan: split LRU lists into anon & file sets), but that's a red herring. It turns out that lguest never hooked up the pte_update/pte_update_defer calls, so our ptes were not always in sync. After the vmscan commit, the bug became reproducible; now a fsck in a 64MB guest causes reproducible pagetable corruption. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: jeremy@xensource.com Cc: virtualization@lists.osdl.org Cc: stable@kernel.org Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02VM, x86, PAT: Change is_linear_pfn_mapping to not use vm_pgoffPallipadi, Venkatesh
upstream commit: 4bb9c5c02153dfc89a6c73a6f32091413805ad7d Impact: fix false positive PAT warnings - also fix VirtalBox hang Use of vma->vm_pgoff to identify the pfnmaps that are fully mapped at mmap time is broken. vm_pgoff is set by generic mmap code even for cases where drivers are setting up the mappings at the fault time. The problem was originally reported here: http://marc.info/?l=linux-kernel&m=123383810628583&w=2 Change is_linear_pfn_mapping logic to overload VM_INSERTPAGE flag along with VM_PFNMAP to mean full PFNMAP setup at mmap time. Problem also tracked at: http://bugzilla.kernel.org/show_bug.cgi?id=12800 Reported-by: Thomas Hellstrom <thellstrom@vmware.com> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Nick Piggin <npiggin@suse.de> Cc: "ebiederm@xmission.com" <ebiederm@xmission.com> Cc: <stable@kernel.org> # only for 2.6.29.1, not .28 LKML-Reference: <20090313004527.GA7176@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRsAndreas Herrmann
upstream commit: 3ff42da5048649503e343a32be37b14a6a4e8aaf Impact: bug fix + BIOS workaround BIOS is expected to clear the SYSCFG[MtrrFixDramModEn] on AMD CPUs after fixed MTRRs are configured. Some BIOSes do not clear SYSCFG[MtrrFixDramModEn] on BP (and on APs). This can lead to obfuscation in Linux when this bit is not cleared on BP but cleared on APs. A consequence of this is that the saved fixed-MTRR state (from BP) differs from the fixed-MTRRs of APs -- because RdDram/WrDram bits are read as zero when SYSCFG[MtrrFixDramModEn] is cleared -- and Linux tries to sync fixed-MTRR state from BP to AP. This implies that Linux sets SYSCFG[MtrrFixDramEn] and activates those bits. More important is that (some) systems change these bits in SMM when ACPI is enabled. Hence it is racy if Linux modifies RdMem/WrMem bits, too. (1) The patch modifies an old fix from Bernhard Kaindl to get suspend/resume working on some Acer Laptops. Bernhard's patch tried to sync RdMem/WrMem bits of fixed MTRR registers and that helped on those old Laptops. (Don't ask me why -- can't test it myself). But this old problem was not the motivation for the patch. (See http://lkml.org/lkml/2007/4/3/110) (2) The more important effect is to fix issues on some more current systems. On those systems Linux panics or just freezes, see http://bugzilla.kernel.org/show_bug.cgi?id=11541 (and also duplicates of this bug: http://bugzilla.kernel.org/show_bug.cgi?id=11737 http://bugzilla.kernel.org/show_bug.cgi?id=11714) The affected systems boot only using acpi=ht, acpi=off or when the kernel is built with CONFIG_MTRR=n. The acpi options prevent full enablement of ACPI. Obviously when ACPI is enabled the BIOS/SMM modfies RdMem/WrMem bits. When CONFIG_MTRR=y Linux also accesses and modifies those bits when it needs to sync fixed-MTRRs across cores (Bernhard's fix, see (1)). How do you synchronize that? You can't. As a consequence Linux shouldn't touch those bits at all (Rationale are AMD's BKDGs which recommend to clear the bit that makes RdMem/WrMem accessible). This is the purpose of this patch. And (so far) this suffices to fix (1) and (2). I suggest not to touch RdDram/WrDram bits of fixed-MTRRs and SYSCFG[MtrrFixDramEn] and to clear SYSCFG[MtrrFixDramModEn] as suggested by AMD K8, and AMD family 10h/11h BKDGs. BIOS is expected to do this anyway. This should avoid that Linux and SMM tread on each other's toes ... Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: trenn@suse.de Cc: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <20090312163937.GH20716@alberich.amd.com> Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02x86: ptrace, bts: fix an unreachable statementxiyou.wangcong@gmail.com
upstream commit: 5a8ac9d28dae5330c70562c7d7785f5104059c17 Commit c2724775ce57c98b8af9694857b941dc61056516 put a statement after return, which makes that statement unreachable. Move that statement before return. Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Roland McGrath <roland@redhat.com> Cc: Markus Metzger <markus.t.metzger@intel.com> LKML-Reference: <20090313075622.GB8933@hack> Cc: <stable@kernel.org> # .29 only Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02x86: fix 64k corruption-checkYinghai Lu
upstream commit: 6d7942dc2a70a7e74c352107b150265602671588 Impact: fix boot crash Need to exit early if the addr is far above 64k. The crash got exposed by: 78a8b35: x86: make e820_update_range() handle small range update Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: <stable@kernel.org> LKML-Reference: <49BC2279.2030101@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02x86, uv: fix cpumask iterator in uv_bau_init()Rusty Russell
upstream commit: 2c74d66624ddbda8101d54d1e184cf9229b378bc Impact: fix boot crash on UV systems Commit 76ba0ecda0de9accea9a91cb6dbde46782110e1c "cpumask: use cpumask_var_t in uv_flush_tlb_others" used cur_cpu as an iterator; it was supposed to be zero for the code below it. Reported-by: Cliff Wickman <cpw@sgi.com> Original-From: Cliff Wickman <cpw@sgi.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Mike Travis <travis@sgi.com> Cc: steiner@sgi.com Cc: <stable@kernel.org> LKML-Reference: <200903180822.31196.rusty@rustcorp.com.au> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02x86, PAT, PCI: Change vma prot in pci_mmap to reflect inherited protPallipadi, Venkatesh
upstream commit: 9cdec049389ce2c324fd1ec508a71528a27d4a07 While looking at the issue in the thread: http://marc.info/?l=dri-devel&m=123606627824556&w=2 noticed a bug in pci PAT code and memory type setting. PCI mmap code did not set the proper protection in vma, when it inherited protection in reserve_memtype. This bug only affects the case where there exists a WC mapping before X does an mmap with /proc or /sys pci interface. This will cause X userlevel mmap from /proc or /sysfs to fail on fork. Reported-by: Kevin Winchester <kjwinchester@gmail.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dave Airlie <airlied@redhat.com> Cc: <stable@kernel.org> LKML-Reference: <20090323190720.GA16831@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02ARM: 5435/1: fix compile warning in sanity_check_meminfo()Mikael Pettersson
upstream commit: f0bba9f934517533acbda7329be93f55d5a01c03 Compiling recent 2.6.29-rc kernels for ARM gives me the following warning: arch/arm/mm/mmu.c: In function 'sanity_check_meminfo': arch/arm/mm/mmu.c:697: warning: comparison between pointer and integer This is because commit 3fd9825c42c784a59b3b90bdf073f49d4bb42a8d "[ARM] 5402/1: fix a case of wrap-around in sanity_check_meminfo()" in 2.6.29-rc5-git4 added a comparison of a pointer with PAGE_OFFSET, which is an integer. Fixed by casting PAGE_OFFSET to void *. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02ARM: twl4030 - leak fixAlan Cox
upstream commit: 803c78e4da28d7d7cb0642caf643b9289ae7838a Trivial error path leak fix. Problem found by Daniel Marjamäki using cppcheck Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02ARM: fix leak in iop13xx/pciAlan Cox
upstream commit: b23c7a427e4b3764ad686a46de89ab652811c50a Another leak found by Daniel Marjamäki Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02ARM: 5428/1: Module relocation update for R_ARM_V4BXDaniel Silverstone
upstream commit: 4731f8b66dd34ebf0e67ca6ba9162b0e509bec06 It would seem when building kernel modules with modern binutils (required by modern GCC) for ARM v4T targets (specifically observed with the Samsung 24xx SoC which is an 920T) R_ARM_V4BX relocations are emitted for function epilogues. This manifests at module load time with an "unknown relocation: 40" error message. The following patch adds the R_ARM_V4BX relocation to the ARM kernel module loader. The relocation operation is taken from that within the binutils bfd library. Signed-off-by: Simtec Linux Team <linux@simtec.co.uk> Signed-off-by: Vincent Sanders <vince@simtec.co.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02KVM: SVM: set accessed bit for VMCB segment selectorsAndre Przywara
upstream commit: 1fbdc7a58512a6283e10fd27108197679db95ffa In the segment descriptor _cache_ the accessed bit is always set (although it can be cleared in the descriptor itself). Since Intel checks for this condition on a VMENTRY, set this bit in the AMD path to enable cross vendor migration. Cc: stable@kernel.org Signed-off-by: Andre Przywara <andre.przywara@amd.com> Acked-By: Amit Shah <amit.shah@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-02KVM: VMX: Don't allow uninhibited access to EFER on i386Avi Kivity
upstream commit: 16175a796d061833aacfbd9672235f2d2725df65 vmx_set_msr() does not allow i386 guests to touch EFER, but they can still do so through the default: label in the switch. If they set EFER_LME, they can oops the host. Fix by having EFER access through the normal channel (which will check for EFER_LME) even on i386. Reported-and-tested-by: Benjamin Gilbert <bgilbert@cs.cmu.edu> Cc: stable@kernel.org Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-03-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: sparc64: Fix crash with /proc/iomem sparc64: Reschedule KGDB capture to a software interrupt. sbus: Auto-load openprom module when device opened.
2009-03-23Merge branch 'merge' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc: powerpc/mm: Fix Respect _PAGE_COHERENT on classic ppc32 SW TLB load machines
2009-03-23powerpc/mm: Fix Respect _PAGE_COHERENT on classic ppc32 SW TLB load machinesKumar Gala
Grant picked up the wrong version of "Respect _PAGE_COHERENT on classic ppc32 SW" (commit a4bd6a93c3f14691c8a29e53eb04dc734b27f0db) It was missing the code to actually deal with the fixup of _PAGE_COHERENT based on the CPU feature. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2009-03-22Merge branch 'fix-includes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu * 'fix-includes' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: merge the non-MMU and MMU versions of siginfo.h m68k: use the MMU version of unistd.h for all m68k platforms m68k: merge the non-MMU and MMU versions of signal.h m68k: merge the non-MMU and MMU versions of ptrace.h m68k: use MMU version of setup.h for both MMU and non-MMU m68k: merge the non-MMU and MMU versions of sigcontext.h m68k: merge the non-MMU and MMU versions of swab.h m68k: merge the non-MMU and MMU versions of param.h
2009-03-19Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6Linus Torvalds
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] make page table upgrade work again [S390] make page table walking more robust [S390] Dont check for pfn_valid() in uaccess_pt.c [S390] ftrace/mcount: fix kernel stack backchain [S390] topology: define SD_MC_INIT to fix performance regression [S390] __div64_31 broken for CONFIG_MARCH_G5
2009-03-18Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller
2009-03-18sparc64: Fix crash with /proc/iomemMikulas Patocka
When you compile kernel on Sparc64 with heap memory checking and type "cat /proc/iomem", you get a crash, because pointers in struct resource are uninitialized. Most code fills struct resource with zeros, so I assume that it is responsibility of the caller of request_resource to initialized it, not the responsibility of request_resource functuion. After 2.6.29 is out, there could be a check for uninitialized fields added to request_resource to avoid crashes like this. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-18sparc64: Reschedule KGDB capture to a software interrupt.David S. Miller
Otherwise it might interrupt switch_to() midstream and use half-cooked register window state. Reported-by: Chris Torek <chris.torek@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-18Merge branch 'merge' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/ps3: ps3_defconfig updates powerpc/mm: Respect _PAGE_COHERENT on classic ppc32 SW powerpc/5200: Enable CPU_FTR_NEED_COHERENT for MPC52xx ps3/block: Replace mtd/ps3vram by block/ps3vram
2009-03-18[S390] make page table upgrade work againMartin Schwidefsky
After TASK_SIZE now gives the current size of the address space the upgrade of a 64 bit process from 3 to 4 levels of page table needs to use the arch_mmap_check hook to catch large mmap lengths. The get_unmapped_area* functions need to check for -ENOMEM from the arch_get_unmapped_area*, upgrade the page table and retry. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-03-18[S390] make page table walking more robustMartin Schwidefsky
Make page table walking on s390 more robust. The current code requires that the pgd/pud/pmd/pte loop is only done for address ranges that are below the end address of the last vma of the address space. But this is not always true, e.g. the generic page table walker does not guarantee this. Change TASK_SIZE/TASK_SIZE_OF to reflect the current size of the address space. This makes the generic page table walker happy but it breaks the upgrade of a 3 level page table to a 4 level page table. To make the upgrade work again another fix is required. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-03-18[S390] Dont check for pfn_valid() in uaccess_pt.cGerald Schaefer
pfn_valid() actually checks for a valid struct page and not for a valid pfn. Using xip mappings w/o struct pages, this will result in -EFAULT returned by the (page table walk) user copy functions, even though there is valid memory. Those user copy functions don't need a struct page, so this patch just removes the pfn_valid() check. Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-03-18[S390] ftrace/mcount: fix kernel stack backchainHeiko Carstens
With packed stack the backchain is at a different location. Just use __SF_BACKCHAIN as an offset to store the backchain. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-28 19:50:39 +0000