linux-stable.git/arch, branch v3.0.6

ARM: 7099/1: futex: preserve oldval in SMP __futex_atomic_op

2011-10-03T18:41:06+00:00

commit df77abcafc8dc881b6c9347548651777088e4b27 upstream.

The SMP implementation of __futex_atomic_op clobbers oldval with the
status flag from the exclusive store. This causes it to always read as
zero when performing the FUTEX_OP_CMP_* operation.

This patch updates the ARM __futex_atomic_op implementations to take a
tmp argument, allowing us to store the strex status flag without
overwriting the register containing oldval.

Reported-by: Minho Ban 
Reviewed-by: Nicolas Pitre 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7091/1: errata: D-cache line maintenance operation by MVA may not succeed

2011-10-03T18:41:06+00:00

commit f630c1bdfbf8fe423325beaf60027cfc7fd7c610 upstream.

This patch implements a workaround for erratum 764369 affecting
Cortex-A9 MPCore with two or more processors (all current revisions).
Under certain timing circumstances, a data cache line maintenance
operation by MVA targeting an Inner Shareable memory region may fail to
proceed up to either the Point of Coherency or to the Point of
Unification of the system. This workaround adds a DSB instruction before
the relevant cache maintenance functions and sets a specific bit in the
diagnostic control register of the SCU.

Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Tested-by: Mark Rutland 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: dma-mapping: free allocated page if unable to map

2011-10-03T18:41:06+00:00

commit d8e89b47e00ee80e920761145144640aac4cf71a upstream.

If the attempt to map a page for DMA fails (eg, because we're out of
mapping space) then we must not hold on to the page we allocated for
DMA - doing so will result in a memory leak.

Reported-by: Bryan Phillippe 
Tested-by: Bryan Phillippe 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

perf, x86: Add model 45 SandyBridge support

2011-10-03T18:40:49+00:00

commit a34668f6beb4ab01e07683276d6a24bab6c175e0 upstream.

Add support to Romely-EP SandyBridge.

Signed-off-by: Youquan Song 
Signed-off-by: Anhua Xu 
Signed-off-by: Lin Ming 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1312264895-2010-1-git-send-email-youquan.song@intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen/e820: if there is no dom0_mem=, don't tweak extra_pages.

2011-10-03T18:40:39+00:00

commit e3b73c4a25e9a5705b4ef28b91676caf01f9bc9f upstream.

The patch "xen: use maximum reservation to limit amount of usable RAM"
(d312ae878b6aed3912e1acaaf5d0b2a9d08a4f11) breaks machines that
do not use 'dom0_mem=' argument with:

reserve RAM buffer: 000000133f2e2000 - 000000133fffffff
(XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
...

The reason being that the last E820 entry is created using the
'extra_pages' (which is based on how many pages have been freed).
The mentioned git commit sets the initial value of 'extra_pages'
using a hypercall which returns the number of pages (if dom0_mem
has been used) or -1 otherwise. If the later we return with
MAX_DOMAIN_PAGES as basis for calculation:

    return min(max_pages, MAX_DOMAIN_PAGES);

and use it:

     extra_limit = xen_get_max_pages();
     if (extra_limit >= max_pfn)
             extra_pages = extra_limit - max_pfn;
     else
             extra_pages = 0;

which means we end up with extra_pages = 128GB in PFNs (33554432)
- 8GB in PFNs (2097152, on this specific box, can be larger or smaller),
and then we add that value to the E820 making it:

  Xen: 00000000ff000000 - 0000000100000000 (reserved)
  Xen: 0000000100000000 - 000000133f2e2000 (usable)

which is clearly wrong. It should look as so:

  Xen: 00000000ff000000 - 0000000100000000 (reserved)
  Xen: 0000000100000000 - 000000027fbda000 (usable)

Naturally this problem does not present itself if dom0_mem=max:X
is used.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen: use maximum reservation to limit amount of usable RAM

2011-10-03T18:40:39+00:00

commit d312ae878b6aed3912e1acaaf5d0b2a9d08a4f11 upstream.

Use the domain's maximum reservation to limit the amount of extra RAM
for the memory balloon. This reduces the size of the pages tables and
the amount of reserved low memory (which defaults to about 1/32 of the
total RAM).

On a system with 8 GiB of RAM with the domain limited to 1 GiB the
kernel reports:

Before:

Memory: 627792k/4472000k available

After:

Memory: 549740k/11132224k available

A increase of about 76 MiB (~1.5% of the unused 7 GiB).  The reserved
low memory is also reduced from 253 MiB to 32 MiB.  The total
additional usable RAM is 329 MiB.

For dom0, this requires at patch to Xen ('x86: use 'dom0_mem' to limit
the number of pages for dom0') (c/s 23790)

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

ARM: Dove: fix second SPI initialization call

2011-10-03T18:40:36+00:00

commit 72cc205611879525db0374d9831f84f787112b25 upstream.

Commit 980f9f601a "ARM: orion: Consolidate SPI initialization."
broke it by overwriting the SPI0 registration.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Make sure iommu->need_sync contains correct value

2011-10-03T18:40:20+00:00

commit f1ca1512e765337a7c09eb875eedef8ea4e07654 upstream.

The value is only set to true but never set back to false,
which causes to many completion-wait commands to be sent to
hardware. Fix it with this patch.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Don't take domain->lock recursivly

2011-10-03T18:40:20+00:00

commit e33acde91140f1809952d1c135c36feb66a51887 upstream.

The domain_flush_devices() function takes the domain->lock.
But this function is only called from update_domain() which
itself is already called unter the domain->lock. This causes
a deadlock situation when the dma-address-space of a domain
grows larger than 1GB.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

ARM: davinci: fix cache flush build error

2011-10-03T18:40:13+00:00

commit 897a6a1a14837d6d582bfd1fd7aba00be44b6469 upstream.

The TNET variant of DaVinci compiles some code that it shares
with other DaVinci variants, however it has a V6 CPU rather than
an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all()
in sleep.S will obviously fail, and we need to build with the
v6_flush_kern_cache_all() call instead. This was triggered by
manually altering the DaVinci config to build the TNET version.

Cc: Dave Martin 
Cc: Arnd Bergmann 
Signed-off-by: Linus Walleij 
Signed-off-by: Sekhar Nori 
Signed-off-by: Greg Kroah-Hartman