linux-toradex.git/arch, branch v3.0.75

ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon

2013-04-26T04:23:48+00:00

commit cd272d1ea71583170e95dde02c76166c7f9017e6 upstream.

On Feroceon the L2 cache becomes non-coherent with the CPU
when the L1 caches are disabled. Thus the L2 needs to be invalidated
after both L1 caches are disabled.

On kexec before the starting the code for relocation the kernel,
the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
but after L2 cache is never invalidated, because inv_all is not set
in cache-feroceon-l2.c.
So kernel relocation and decompression may has (and usually has) errors.
Setting the function enables L2 invalidation and fixes the issue.

Signed-off-by: Illia Ragozin 
Acked-by: Jason Cooper 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

KVM: Allow cross page reads and writes from cached translations.

2013-04-26T04:23:48+00:00

commit 8f964525a121f2ff2df948dac908dcc65be21b5b upstream.

This patch adds support for kvm_gfn_to_hva_cache_init functions for
reads and writes that will cross a page.  If the range falls within
the same memslot, then this will be a fast operation.  If the range
is split between two memslots, then the slower kvm_read_guest and
kvm_write_guest are used.

Tested: Test against kvm_clock unit tests.

Signed-off-by: Andrew Honig 
Signed-off-by: Gleb Natapov 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache functions (CVE-2013-1797)

2013-04-26T04:23:48+00:00

commit 0b79459b482e85cb7426aa7da683a9f2c97aeae1 upstream.

There is a potential use after free issue with the handling of
MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
memory such as frame buffers then KVM might continue to write to that
address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
the page in memory so it's unlikely to cause an issue, but if the user
space component re-purposes the memory previously used for the guest, then
the guest will be able to corrupt that memory.

Tested: Tested against kvmclock unit test

Signed-off-by: Andrew Honig 
Signed-off-by: Marcelo Tosatti 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: fix for buffer overflow in handling of MSR_KVM_SYSTEM_TIME (CVE-2013-1796)

2013-04-26T04:23:47+00:00

commit c300aa64ddf57d9c5d9c898a64b36877345dd4a9 upstream.

If the guest sets the GPA of the time_page so that the request to update the
time straddles a page then KVM will write onto an incorrect page.  The
write is done byusing kmap atomic to get a pointer to the page for the time
structure and then performing a memcpy to that page starting at an offset
that the guest controls.  Well behaved guests always provide a 32-byte aligned
address, however a malicious guest could use this to corrupt host kernel
memory.

Tested: Tested against kvmclock unit test.

Signed-off-by: Andrew Honig 
Signed-off-by: Marcelo Tosatti 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal

2013-04-17T04:02:31+00:00

commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.

Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.

Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.

[ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
  updates" may cause a minor performance regression on
  bare metal.  This patch resolves that performance regression.  It is
  somewhat unclear to me if this is a good -stable candidate. ]

Signed-off-by: Boris Ostrovsky 
Link: http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.wilk@oracle.com
Tested-by: Josh Boyer 
Tested-by: Konrad Rzeszutek Wilk 
Acked-by: Borislav Petkov 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates

2013-04-17T04:02:31+00:00

commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.

In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.

One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:

- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
  which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
  PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries

The OOPs usually looks as so:

------------[ cut here ]------------
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: 0000 [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[]  [] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
 [] do_page_fault+0x399/0x4b0
 [] ? xen_mc_extend_args+0xec/0x110
 [] page_fault+0x25/0x30
 [] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
 [] __mem_cgroup_uncharge_common+0xd8/0x350
 [] mem_cgroup_uncharge_page+0x57/0x60
 [] page_remove_rmap+0xe0/0x150
 [] ? vm_normal_page+0x1a/0x80
 [] unmap_single_vma+0x531/0x870
 [] unmap_vmas+0x52/0xa0
 [] ? pte_mfn_to_pfn+0x72/0x100
 [] exit_mmap+0x98/0x170
 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [] mmput+0x83/0xf0
 [] exit_mm+0x104/0x130
 [] do_exit+0x15a/0x8c0
 [] do_group_exit+0x3f/0xa0
 [] sys_exit_group+0x17/0x20
 [] system_call_fastpath+0x16/0x1b

Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.

RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer 
Reported-and-Tested-by: Krishna Raman 
Signed-off-by: Samu Kallio 
Link: http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.wilk@oracle.com
Tested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86-32, mm: Rip out x86_32 NUMA remapping code

2013-04-17T04:02:30+00:00

commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.

[was already included in 3.0, but I missed the patch hunk for 
 arch/x86/mm/numa_32.c  - gregkh]

This code was an optimization for 32-bit NUMA systems.

It has probably been the cause of a number of subtle bugs over
the years, although the conditions to excite them would have
been hard to trigger.  Essentially, we remap part of the kernel
linear mapping area, and then sometimes part of that area gets
freed back in to the bootmem allocator.  If those pages get
used by kernel data structures (say mem_map[] or a dentry),
there's no big deal.  But, if anyone ever tried to use the
linear mapping for these pages _and_ cared about their physical
address, bad things happen.

For instance, say you passed __GFP_ZERO to the page allocator
and then happened to get handed one of these pages, it zero the
remapped page, but it would make a pte to the _old_ page.
There are probably a hundred other ways that it could screw
with things.

We don't need to hang on to performance optimizations for
these old boxes any more.  All my 32-bit NUMA systems are long
dead and buried, and I probably had access to more than most
people.

This code is causing real things to break today:

	https://lkml.org/lkml/2013/1/9/376

I looked in to actually fixing this, but it requires surgery
to way too much brittle code, as well as stuff like
per_cpu_ptr_to_phys().

[ hpa: Cc: this for -stable, since it is a memory corruption issue.
  However, an alternative is to simply mark NUMA as depends BROKEN
  rather than EXPERIMENTAL in the X86_32 subclause... ]

Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com
Signed-off-by: H. Peter Anvin 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

x86-32, mm: Rip out x86_32 NUMA remapping code

2013-04-12T16:18:10+00:00

commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.

This code was an optimization for 32-bit NUMA systems.

It has probably been the cause of a number of subtle bugs over
the years, although the conditions to excite them would have
been hard to trigger.  Essentially, we remap part of the kernel
linear mapping area, and then sometimes part of that area gets
freed back in to the bootmem allocator.  If those pages get
used by kernel data structures (say mem_map[] or a dentry),
there's no big deal.  But, if anyone ever tried to use the
linear mapping for these pages _and_ cared about their physical
address, bad things happen.

For instance, say you passed __GFP_ZERO to the page allocator
and then happened to get handed one of these pages, it zero the
remapped page, but it would make a pte to the _old_ page.
There are probably a hundred other ways that it could screw
with things.

We don't need to hang on to performance optimizations for
these old boxes any more.  All my 32-bit NUMA systems are long
dead and buried, and I probably had access to more than most
people.

This code is causing real things to break today:

	https://lkml.org/lkml/2013/1/9/376

I looked in to actually fixing this, but it requires surgery
to way too much brittle code, as well as stuff like
per_cpu_ptr_to_phys().

[ hpa: Cc: this for -stable, since it is a memory corruption issue.
  However, an alternative is to simply mark NUMA as depends BROKEN
  rather than EXPERIMENTAL in the X86_32 subclause... ]

Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com
Signed-off-by: H. Peter Anvin 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being performed before the ANDCOND test

2013-04-12T16:18:09+00:00

commit 9fb2640159f9d4f5a2a9d60e490482d4cbecafdb upstream.

Some versions of pHyp will perform the adjunct partition test before the
ANDCOND test.  The result of this is that H_RESOURCE can be returned and
cause the BUG_ON condition to occur. The HPTE is not removed.  So add a
check for H_RESOURCE, it is ok if this HPTE is not removed as
pSeries_lpar_hpte_remove is looking for an HPTE to remove and not a
specific HPTE to remove.  So it is ok to just move on to the next slot
and try again.

Signed-off-by: Michael Wolf 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Greg Kroah-Hartman

alpha: Add irongate_io to PCI bus resources

2013-04-12T16:18:09+00:00

commit aa8b4be3ac049c8b1df2a87e4d1d902ccfc1f7a9 upstream.

Fixes a NULL pointer dereference at boot on UP1500.

Reviewed-and-Tested-by: Matt Turner 
Signed-off-by: Jay Estabrook 
Signed-off-by: Matt Turner 
Signed-off-by: Michael Cree 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman