linux-stable.git/arch, branch linux-2.6.37.y

x86: Cleanup highmap after brk is concluded

2011-03-27T19:00:34+00:00

commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream.

Now cleanup_highmap actually is in two steps: one is early in head64.c
and only clears above _end; a second one is in init_memory_mapping() and
tries to clean from _brk_end to _end.
It should check if those boundaries are PMD_SIZE aligned but currently
does not.
Also init_memory_mapping() is called several times for numa or memory
hotplug, so we really should not handle initial kernel mappings there.

This patch moves cleanup_highmap() down after _brk_end is settled so
we can do everything in one step.
Also we honor max_pfn_mapped in the implementation of cleanup_highmap.

Signed-off-by: Yinghai Lu 
Signed-off-by: Stefano Stabellini 
LKML-Reference: 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

sh: Fix ptrace hw_breakpoint handling

2011-03-27T19:00:24+00:00

commit fb7f045ace0624f1e59a7db8497e460bd54b1cbc upstream.

Since commit 34d0b5af50a063cded842716633501b38ff815fb it is no longer
possible to debug an application using singlestep. The old commit
converted singlestep handling via ptrace to hw_breakpoints. The
hw_breakpoint is disabled when an event is triggered and not re-enabled
again. This patch re-enables the existing hw_breakpoint before the
existing breakpoint is reused.

Signed-off-by: David Engraf 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

sh: Fix ptrace fpu state initialisation

2011-03-27T19:00:24+00:00

commit c49b6ecf0870e78fa40497cd8b142915c1d5c7c9 upstream.

Commit 0ea820cf introduced the PTRACE_GETFPREGS/SETFPREGS cmds,
but gdb-server still accesses the FPU state using the
PTRACE_PEEKUSR/POKEUSR commands. In this case, xstate was not
initialised.

Signed-off-by: Phil Edworthy 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

intel_idle: disable Atom/Lincroft HW C-state auto-demotion

2011-03-27T19:00:14+00:00

commit bfb53ccf1c734b1907df7189eef4c08489827951 upstream.

Just as we had to disable auto-demotion for NHM/WSM,
we need to do the same for Atom (Lincroft version).

In particular, auto-demotion will prevent Lincroft
from entering the S0i3 idle power saving state.

https://bugzilla.kernel.org/show_bug.cgi?id=25252

Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

intel_idle: disable NHM/WSM HW C-state auto-demotion

2011-03-27T19:00:13+00:00

commit 14796fca2bd22acc73dd0887248d003b0f441d08 upstream.

Hardware C-state auto-demotion is a mechanism where the HW overrides
the OS C-state request, instead demoting to a shallower state,
which is less expensive, but saves less power.

Modern Linux should generally get exactly the states it requests.
In particular, when a CPU is taken off-line, it must not be demoted, else
it can prevent the entire package from reaching deep C-states.

https://bugzilla.kernel.org/show_bug.cgi?id=25252

Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

xen: set max_pfn_mapped to the last pfn mapped

2011-03-27T19:00:13+00:00

commit 14988a4d350ce3b41ecad4f63c4f44c56f5ae34d upstream.

Do not set max_pfn_mapped to the end of the initial memory mappings,
that also contain pages that don't belong in pfn space (like the mfn
list).

Set max_pfn_mapped to the last real pfn mapped in the initial memory
mappings that is the pfn backing _end.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
LKML-Reference: 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, binutils, xen: Fix another wrong size directive

2011-03-23T19:50:46+00:00

commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream.

The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
yet another time, under CONFIG_XEN=y due to a .size directive that
refers to a slightly differently named (hence, to the now very
strict and unforgiving assembler, non-existent) symbol.

[ mingo:

   This unnecessary build breakage caused by new binutils
   version 2.21 gets escallated back several kernel releases spanning
   several years of Linux history, affecting over 130,000 upstream
   kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
   affecting all major Linux distro kernel configs).

   Git annotate tells us that this slight debug symbol code mismatch
   bug has been introduced in 2008 in commit 3d75e1b8:

     3d75e1b8        (Jeremy Fitzhardinge    2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)

   The 'bug' is just a slight assymetry in ENTRY()/END()
   debug-symbols sequences, with lots of assembly code between the
   ENTRY() and the END():

     ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
       ...
     END(do_hypervisor_callback)

   Human reviewers almost never catch such small mismatches, and binutils
   never even warned about it either.

   This new binutils version thus breaks the Xen build on all upstream kernels
   since v2.6.27, out of the blue.

   This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
   impossible on such binutils, for a bisection window of over hundred
   thousand historic commits. (!)

   This is a major fail on the side of binutils and binutils needs to turn
   this show-stopper build failure into a warning ASAP. ]

Signed-off-by: Alexander van Heukelum 
Cc: Jeremy Fitzhardinge 
Cc: Jan Beulich 
Cc: H.J. Lu 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: "H. Peter Anvin" 
Cc: Kees Cook 
LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

fix per-cpu flag problem in the cpu affinity checkers

2011-03-23T19:50:42+00:00

commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream.

The CHECK_IRQ_PER_CPU is wrong, it should be checking
irq_to_desc(irq)->status not just irq.

Signed-off-by: Thomas Gleixner 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

x86: Flush TLB if PGD entry is changed in i386 PAE mode

2011-03-23T19:50:40+00:00

commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream.

According to intel CPU manual, every time PGD entry is changed in i386 PAE
mode, we need do a full TLB flush. Current code follows this and there is
comment for this too in the code.

But current code misses the multi-threaded case. A changed page table
might be used by several CPUs, every such CPU should flush TLB. Usually
this isn't a problem, because we prepopulate all PGD entries at process
fork. But when the process does munmap and follows new mmap, this issue
will be triggered.

When it happens, some CPUs keep doing page faults:

  http://marc.info/?l=linux-kernel&m=129915020508238&w=2

Reported-by: Yasunori Goto
Tested-by: Yasunori Goto
Reviewed-by: Rik van Riel 
Signed-off-by: Shaohua Li
Cc: Mallick Asit K 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: linux-mm 
LKML-Reference: <1300246649.2337.95.camel@sli10-conroe>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf, powerpc: Handle events that raise an exception without overflowing

2011-03-23T19:50:36+00:00

commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 upstream.

Events on POWER7 can roll back if a speculative event doesn't
eventually complete. Unfortunately in some rare cases they will
raise a performance monitor exception. We need to catch this to
ensure we reset the PMC. In all cases the PMC will be 256 or less
cycles from overflow.

Signed-off-by: Anton Blanchard 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <20110309143842.6c22845e@kryten>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman