Merge branch 'out-of-tree'

Merge branch 'build' into auto-latest

Merge branch 'tracing/immediates' into auto-latest

Conflicts:

include/asm-x86/kdebug.h
init/main.c
kernel/fork.c

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'tracing/stopmachine-allcpus' into auto-latest

Merge branch 'tracing/nmisafe' into auto-latest

Merge branch 'tracing/textedit' into auto-latest

Merge branch 'tracing/markers' into auto-latest

Conflicts:

kernel/fork.c

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'x86/pebs' into auto-latest

Conflicts:

arch/x86/kernel/setup_64.c

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'timers/hrtimers' into auto-latest

Merge branch 'timers/hpet' into auto-latest

Merge branch 'timers/nohz' into auto-latest

Merge branch 'timers/posixtimers' into auto-latest

Merge branch 'timers/clockevents' into auto-latest

Merge branch 'stackprotector' into auto-latest

Merge branch 'sched-devel' into auto-latest

Conflicts:

kernel/Makefile

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'safe-poison-pointers' into auto-latest

Merge branch 'pci-for-jesse' into auto-latest

Merge branch 'kmemcheck' into auto-latest

Conflicts:

include/asm-x86/pgtable.h

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'tracing/ftrace-mergefixups' into auto-latest

Merge branch 'cpus4096' into auto-latest

Merge branch 'core/urgent' into auto-latest

Merge branch 'core/futex-64bit' into auto-latest

Merge branch 'core/stacktrace' into auto-latest

Merge branch 'core/softlockup' into auto-latest

Merge branch 'core/softirq' into auto-latest

Merge branch 'core/rodata' into auto-latest

Merge branch 'core/printk' into auto-latest

Merge branch 'core/percpu' into auto-latest

Merge branch 'core/locking' into auto-latest

Merge branch 'tracing/mmiotrace-mergefixups' into auto-latest

Merge branch 'auto-ftrace-next' into auto-latest

Merge branch 'auto-x86-next' into auto-latest

Merge branch 'x86/mmio' into auto-x86-next

Merge branch 'x86/setup' into auto-x86-next

Merge branch 'x86/xen' into auto-x86-next

Merge branch 'x86/vdso' into auto-x86-next

Merge branch 'x86/timers' into auto-x86-next

Merge branch 'x86/threadinfo' into auto-x86-next

Merge branch 'x86/resumetrace' into auto-x86-next

Merge branch 'x86/ptemask' into auto-x86-next

Merge branch 'x86/pat' into auto-x86-next

Merge branch 'x86/numa' into auto-x86-next

Conflicts:

arch/x86/Kconfig
arch/x86/kernel/nmi.c
arch/x86/kernel/setup_32.c

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'x86/nmi' into auto-x86-next

Conflicts:

arch/x86/kernel/nmi.c
arch/x86/kernel/nmi_32.c

Merge branch 'x86/mpparse' into auto-x86-next

Merge branch 'x86/memtest' into auto-x86-next

Merge branch 'x86/mce' into auto-x86-next

Merge branch 'x86/ldt' into auto-x86-next

Merge branch 'x86/kconfig' into auto-x86-next

Merge branch 'x86/irqstats' into auto-x86-next

Merge branch 'x86/irq' into auto-x86-next

Conflicts:

arch/x86/kernel/i8259.c
arch/x86/kernel/irqinit_64.c

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'x86/intel' into auto-x86-next

Merge branch 'x86/i8259' into auto-x86-next

Merge branch 'x86/gart' into auto-x86-next

Merge branch 'x86/defconfig' into auto-x86-next

Merge branch 'x86/cpu' into auto-x86-next

Conflicts:

arch/x86/kernel/setup_64.c
include/asm-x86/mmconfig.h

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Merge branch 'x86/cpa' into auto-x86-next

Merge branch 'x86/cleanups' into auto-x86-next

Merge branch 'x86/build' into auto-x86-next

Merge branch 'x86/bitops' into auto-x86-next

Merge branch 'x86/apm' into auto-x86-next

Merge branch 'x86/apic' into auto-x86-next

Merge branch 'x86/numa-fixes' into auto-x86-next

Merge branch 'x86/urgent' into auto-x86-next

Merge branch 'tracing/sysprof' into auto-ftrace-next

Merge branch 'tracing/mmiotrace' into auto-ftrace-next

Merge branch 'tracing/sched_markers' into auto-ftrace-next

Merge branch 'tracing/ftrace' into auto-ftrace-next

Merge branch 'core/rcu' into auto-sched-next

x86: fix nmi.c build bug

apic.h needs to be included for the apic_write_around() definition.

ftrace: export kretprobe_trampoline for function tracer

Follow suit from kprobe implementations on other archs and make kretprobe_trampoline non-static. Ftrace implmentation (more specifically, kernel/trace/trace.c) requires access to it (see-> http://kerneltrap.org/mailarchive/linux-kernel/2008/5/27/1955234).

Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: IO-APIC - use NMI_NONE instead of numeric constant

Not sure but maybe it is better to use NMI_DISABLED,
will take a look. But for now this patch is not change
anything in logic so it will not hurt/broke the kernel.
For most cases nmi_watchdog assignment is by one of NMI_*
macro so I think there it make sense too.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

tcp: revert DEFER_ACCEPT modifications

On Sat, 31 May 2008, Ilpo Järvinen wrote:

> On Sat, 31 May 2008, Ingo Molnar wrote:
>
> > ok, once i added back the localhost distcc component and the hung kernel
> > build + stuck TCP socket bug happened again overnight:
> >
> >  Active Internet connections (w/o servers)
> >  Proto Recv-Q Send-Q Local Address               Foreign Address             State
> >  tcp    72187      0 10.0.1.14:3632              10.0.1.14:47910             ESTABLISHED
> >  tcp        0 174464 10.0.1.14:47910             10.0.1.14:3632              ESTABLISHED
> >
> > so it seems distcc over localhost was the aspect that made it fail.
> >
> > _Perhaps_ what matters is to have the new post-rc3 TCP code on _both_
> > sides of the connection. But that is just a theory - it could be timing,
> > etc.
>
> Btw, does your distcc perhaps happen enable TCP_DEFER_ACCEPT (there were
> some post 2.6.25 changes into it)?

Hmm, if so, please try this revert below (I hope I got everything that is
related there, gitk is currently broken for me so that viewing many
commits quickly is a pain, so I might have accidently missed something)...

Reverts these commits:
 [TCP]: TCP_DEFER_ACCEPT updates - defer timeout conflicts with max_t
 [TCP]: TCP_DEFER_ACCEPT updates - dont retxmt synack
 [TCP]: TCP_DEFER_ACCEPT updates - process as established
 tcp: Fix slab corruption with ipv6 and tcp6fuzz

..., ie.,
 539fae89bebd16ebeafd57a87169bc56eb530d76,
 e4c78840284f3f51b1896cf3936d60a6033c4d2c,
 ec3c0982a2dd1e671bad8e9d26c28dcba0039d87 and
 9ae27e0adbf471c7a6b80102e38e1d5a346b3b38.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

xen: add new Xen elfnote types and use them appropriately

Define recently added XEN_ELFNOTEs, and use them appropriately.
Most significantly, this enables domain checkpointing (xm save -c).

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

xen: resume timers on all vcpus

On resume, the vcpu timer modes will not be restored.  The timer
infrastructure doesn't do this for us, since it assumes the cpus
are offline.  We can just poke the other vcpus into the right mode
directly though.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

xen: restore vcpu_info mapping

If we're using vcpu_info mapping, then make sure its restored on all
processors before relasing them from stop_machine.

The only complication is that if this fails, we can't continue because
we've already made assumptions that the mapping is available (baked in
calls to the _direct versions of the functions, for example).

Fortunately this can only happen with a 32-bit hypervisor, which may
possibly run out of mapping space.  On a 64-bit hypervisor, this is a
non-issue.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

xen: avoid hypercalls when updating unpinned pud/pmd

When operating on an unpinned pagetable (ie, one under construction or
destruction), it isn't necessary to use a hypercall to update a
pud/pmd entry.  Jan Beulich observed that a similar optimisation
avoided many thousands of hypercalls while doing a kernel build.

One tricky part is that early in the kernel boot there's no page
structure, so we can't check to see if the page is pinned.  In that
case, we just always use the hypercall.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

xen: export get_phys_to_machine

-tip testing found the following xen-console symbols trouble:

  ERROR: "get_phys_to_machine" [drivers/video/xen-fbfront.ko] undefined!
  ERROR: "get_phys_to_machine" [drivers/net/xen-netfront.ko] undefined!
  ERROR: "get_phys_to_machine" [drivers/input/xen-kbdfront.ko] undefined!

with:

  http://redhat.com/~mingo/misc/config-Mon_Jun__2_12_25_13_CEST_2008.bad

printk: export console_drivers

this symbol is needed by drivers/video/xen-fbfront.ko.

sched: print the sd->level in sched_domain_debug code

While printing out the visual representation of the sched-domains, print
the level (MC, SMT, CPU, NODE, ... ) of each of the sched_domains.

Credit: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

suspend-vs-iommu: prevent suspend if we could not resume

iommu/gart support misses suspend/resume code, which can do bad stuff,
including memory corruption on resume.  Prevent system suspend in case we
would be unable to resume.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Tested-by: Patrick <ragamuffin@datacomm.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

suspend-vs-iommu: prevent suspend if we could not resume

iommu/gart support misses suspend/resume code, which can do bad stuff,
including memory corruption on resume.  Prevent system suspend in case we
would be unable to resume.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Tested-by: Patrick <ragamuffin@datacomm.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

sched: update the sched-domains debug documentation

SCHED_DOMAIN_DEBUG mentioned in the Documentation for sched-domains
for enabling sched-domains debugging doesn't exist anymore.

Update the documentation to reflect the correct way of enabling
sched-domain debugging.

Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: section mismatch fix

Fix this:

 WARNING: vmlinux.o(.text+0x114bb): Section mismatch in reference from
 the function nopat() to the function .cpuinit.text:pat_disable()
 The function nopat() references
 the function __cpuinit pat_disable().
 This is often because nopat lacks a __cpuinit
 annotation or the annotation of pat_disable is wrong.

Reported-by: "Fabio Comolli" <fabio.comolli@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

markers: use rcu_barrier_sched() and call_rcu_sched()

It can be seen as a fix since the marker code was using an ugly,
temporary, #ifdef hack to work around CONFIG_PREEMPT_RCU.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Paul McKenney <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86, uv: update macros used by UV platform

Update the UV address macros to better describe the
fields of UV physical addresses. Improve comments
in the header files. Add additional MMR definitions.

Signed-off-by: Jack Steiner <steiner@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: coding style fixes for nmi.c

before
total: 1 errors, 6 warnings, 534 lines checked
after
total: 0 errors, 1 warnings, 532 lines checked

Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: remove duplicated e820 func in setup.h

we already have them in e820.h

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

ftrace: user update and disable dynamic ftrace daemon

In dynamic ftrace, the mcount function starts off pointing to a stub
function that just returns.

On start up, the call to the stub is modified to point to a "record_ip"
function. The job of the record_ip function is to add the function to
a pre-allocated hash list. If the function is already there, it simply is
ignored, otherwise it is added to the list.

Later, a ftraced daemon wakes up and calls kstop_machine if any functions
have been recorded, and changes the calls to the recorded functions to
a simple nop.  If no functions were recorded, the daemon goes back to sleep.

The daemon wakes up once a second to see if it needs to update any newly
recorded functions into nops.  Usually it does not, but if a lot of code
has been executed for the first time in the kernel, the ftraced daemon
will call kstop_machine to update those into nops.

The problem currently is that there's no way to stop the daemon from doing
this, and it can cause unneeded latencies (800us which for some is bothersome).

This patch adds a new file /debugfs/tracing/ftraced_enabled. If the daemon
is active, reading this will return "enabled\n" and "disabled\n" when the
daemon is not running. To disable the daemon, the user can echo "0" or
"disable" into this file, and "1" or "enable" to re-enable the daemon.

Since the daemon is used to convert the functions into nops to increase
the performance of the system, I also added that anytime something is
written into the ftraced_enabled file, kstop_machine will run if there
are new functions that have been detected that need to be converted.

This way the user can disable the daemon but still be able to control the
conversion of the mcount calls to nops by simply,

  "echo 0 > /debugfs/tracing/ftraced_enabled"

when they need to do more conversions.

To see the number of converted functions:

  "cat /debugfs/tracing/dyn_ftrace_total_info"

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: break mutual header inclusion

This breaks up the mutual inclusion between headers ptrace.h and vm86.h
by moving some small part of vm86.h which is needed by ptrace.h into
processor-flags.h.

We also try to move #include lines to the top.

This has been compile tested on x86_32 and x86_64 defconfig, and run
through 'make headers_check'.

Cc: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: fix incomplete include guard in include/asm-x86/seccomp_32.h

Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

ftrace: distinguish kretprobe'd functions in trace logs

Tracing functions via ftrace which have a kretprobe installed on them, can produce misleading output in their trace logs. E.g, consider the correct trace of the following sequence:

do_IRQ()
{
~
  irq_enter();
~
}

Trace log (sample):
<idle>-0     [00] 4154504455.781616: irq_enter <- do_IRQ

But if irq_enter() has a kretprobe installed on it, the return value stored on the stack at each invocation is modified to divert the return to a kprobe trampoline function called kretprobe_trampoline(). So with this the trace would (currently) look like:

<idle>-0     [00] 4154504455.781616: irq_enter <- kretprobe_trampoline

Now this is quite misleading to the end user, as it suggests something that didn't actually happen. So just to avoid such misinterpretations, the inlined patch aims to output such a log as:

<idle>-0     [00] 4154504455.781616: irq_enter <- [unknown/kretprobe'd]

Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

softlockup: fix NMI hangs due to lock race - 2.6.26-rc regression

The touch_nmi_watchdog() routine on x86 ultimately calls
touch_softlockup_watchdog().  The problem is that to touch the
softlockup watchdog, the cpu_clock code has to be called which could
involve multiple cpu locks and can lead to a hard hang if one of the
locks is held by a processor that is not going to return anytime soon
(such as could be the case with kgdb or perhaps even with some other
kind of exception).

This patch causes the public version of the
touch_softlockup_watchdog() to defer the cpu clock access to a later
point.

The test case for this problem is to use the following kernel config
options:

CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100I100000"

It should be noted that kgdb test suite and these options were not
available until 2.6.26-rc2, so it was necessary to patch the kgdb
test suite during the bisection.

I would consider this patch a regression fix because the problem first
appeared in commit 27ec4407790d075c325e1f4da0a19c56953cce23 when some
logic was added to try to periodically sync the clocks.  It was
possible to work around this particular problem by simply not
performing the sync anytime the system was in a critical context.
This was ok until commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd,
which added config option CONFIG_HAVE_UNSTABLE_SCHED_CLOCK and some
multi-cpu locks to sync the clocks.  It became clear that accessing
this code from an nmi was the source of the lockups.  Avoiding the
access to the low level clock code from an code inside the NMI
processing also fixed the problem with the 27ec44... commit.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

softlockup: fix NMI hangs due to lock race - 2.6.26-rc regression

The touch_nmi_watchdog() routine on x86 ultimately calls
touch_softlockup_watchdog().  The problem is that to touch the
softlockup watchdog, the cpu_clock code has to be called which could
involve multiple cpu locks and can lead to a hard hang if one of the
locks is held by a processor that is not going to return anytime soon
(such as could be the case with kgdb or perhaps even with some other
kind of exception).

This patch causes the public version of the
touch_softlockup_watchdog() to defer the cpu clock access to a later
point.

The test case for this problem is to use the following kernel config
options:

CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100I100000"

It should be noted that kgdb test suite and these options were not
available until 2.6.26-rc2, so it was necessary to patch the kgdb
test suite during the bisection.

I would consider this patch a regression fix because the problem first
appeared in commit 27ec4407790d075c325e1f4da0a19c56953cce23 when some
logic was added to try to periodically sync the clocks.  It was
possible to work around this particular problem by simply not
performing the sync anytime the system was in a critical context.
This was ok until commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd,
which added config option CONFIG_HAVE_UNSTABLE_SCHED_CLOCK and some
multi-cpu locks to sync the clocks.  It became clear that accessing
this code from an nmi was the source of the lockups.  Avoiding the
access to the low level clock code from an code inside the NMI
processing also fixed the problem with the 27ec44... commit.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

x86: MMIO and gcc re-ordering issue

On Tue, 27 May 2008, Linus Torvalds wrote:
>
> Expecting people to fix up all drivers is simply not going to happen. And
> serializing things shouldn't be *that* expensive. People who cannot take
> the expense can continue to use the magic __raw_writel() etc stuff.

Of course, for non-x86, you kind of have to expect drivers to be
well-behaved, so non-x86 can probably avoid this simply because there are
less relevant drivers involved.

Here's a UNTESTED patch for x86 that may or may not compile and work, and
which serializes (on a compiler level) the IO accesses against regular
memory accesses.

__read[bwlq]()/__write[bwlq]() are not serialized with a :"memory"
barrier, although since they still use "asm volatile" I suspect that i
practice they are probably serial too. Did not look very closely at any
generated code (only did a trivial test to see that the code looks
*roughly* correct).

Signed-off-by: Ingo Molnar <mingo@elte.hu>

fix build bug in "x86: add PCI extended config space access for AMD Barcelona"

x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

On Wed, 2008-05-28 at 04:47 +0200, Andi Kleen wrote:
> > So...  why not just remove the setting of __GFP_NORETRY?  Why is it
> > wrong to oom-kill things in this case?
>
> When the 16MB zone overflows (which can be common in some workloads)
> calling the OOM killer is pretty useless because it has barely any
> real user data [only exception would be the "only 16MB" case Alan
> mentioned]. Killing random processes in this case is bad.
>
> I think for 16MB __GFP_NORETRY is ok because there should be
> nothing freeable in there so looping is useless. Only exception would be the
> "only 16MB total" case again but I'm not sure 2.6 supports that at all
> on x86.
>
> On the other hand d_a_c() does more allocations than just 16MB, especially
> on 64bit and the other zones need different strategies.

Okay, so how about this then ?

Signed-off-by: Ingo Molnar <mingo@elte.hu>

CONFIG_PM_SLEEP fix: xen: fix compilation when CONFIG_PM_SLEEP is disabled

Xen save/restore depends on CONFIG_PM_SLEEP being set for device_power_up/down.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

build: add __page_aligned_data and __page_aligned_bss

Making a variable page-aligned by using
__attribute__((section(".data.page_aligned"))) is fragile because if
sizeof(variable) is not also a multiple of page size, it leaves
variables in the remainder of the section unaligned.

This patch introduces two new qualifiers, __page_aligned_data and
__page_aligned_bss to set the section *and* the alignment of
variables.  This makes page-aligned variables more robust because the
linker will make sure they're aligned properly.  Unfortunately it
requires *all* page-aligned data to use these macros...

Signed-off-by: Ingo Molnar <mingo@elte.hu>

i8259: fix final ugliness

Introduce IRQx_VECTOR on 32-bit, so that #ifdef noise is kept
down. There should be no object code change.

[ mingo@elte.hu: merged to x86/irq not x86/i8259 due to x86/irq having
  restructured the vector code into asm-x86/irq_vectors.h, which this
  patch touches. ]

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

fix build bug in "x86: add PCI extended config space access for AMD Barcelona"

Signed-off-by: Ingo Molnar <mingo@elte.hu>