When CONFIG_IRQSOFF_TRACER is set and CONFIG_PROVE_LOCKING is not, we
get the following error:

$  make oldconfig
scripts/kconfig/conf --oldconfig arch/x86/Kconfig
warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)

This is because IRQSOFF_TRACER selects TRACE_IRQFLAGS but TRACE_IRQFLAGS
has PROVE_LOCKING as a dependency. This code is incorrect, and
this patch changes the TRACE_IRQFLAGS to be just a simple bool that
does not depend or select anything. Instead both IRQSOFF_TRACER and
PROVE_LOCKING select it.
Reported-by: NRichard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

Merge branch 'perf/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing into perf/core

Conflicts:
	tools/perf/util/callchain.h

Merge reason:
	Fix a non-trivial conflict with latest fixes

Each histogram entry has a callchain root that stores the
callchain samples. However we forgot to initialize the
tracking of children hits of these roots, which then got
random values on their creation.

The root children hits is multiplied by the minimum percentage
of hits provided by the user, and the result becomes the minimum
hits expected from children branches. If the random value due
to the uninitialization is big enough, then this minimum number
of hits can be huge and eventually filter every children branches.

The end result was invisible callchains. All we need to
fix this is to initialize the children hits of the root.
Reported-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: 2.6.32.x-2.6.35.y <stable@kernel.org>

External shared libraries should never be appended to the LDFLAGS as this
messes the linking order. As EXTLIBS collects those libraries, it seems that
perl and python libraries  should also be appended to EXTLIBS.

Also fix the broken linking order.

This is a refresh of a patch by Ozan Çağlayan and improved by both Tom Zanussi
and Kirill A. Shutemov.

Cc: Ozan Çağlayan <ozan@pardus.org.tr>
Tested-by: NKirill A. Shutemov <kirill@shutemov.name>
Tested-by: NTom Zanussi <tzanussi@gmail.com>
LKML-Reference: <1282627430.28324.8.camel@tropicana>
Signed-off-by: NTom Zanussi <tzanussi@gmail.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Given a dso, list the symbols in ascending name order. Needed for
listing available symbols from perf probe.

Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jim Keniston <jkenisto@linux.vnet.ibm.com>
Cc: Mark Wielaard <mjw@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Naren A Devaiah <naren.devaiah@in.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <20100825134329.5447.92261.sendpatchset@localhost6.localdomain6>
Signed-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When looking at a callchains enabled perf data file one can find it
tiresome to start with all callchains collapsed and then to have to go
one by one expanding them.

So associate 'E' with "Expand all callchains" and 'C' with "Collapse all
callchains".

This way now one can have the top level view and then switch to/from
having all callchains expanded.

More work is needed to allow expanding just from one branch down to its
leaves.
Reported-by: NChristoph Hellwig <hch@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Not everytime we show the callchains, removing duplicated initialization
of this field.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Its way too stupid to use rb_first() for just caching if there are
children, use the cheaper RB_EMPTY_ROOT() instead.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It wasn't setting the ms.has_children for the hist_entry itself, just
for the callchain

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <new-submission>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

If on Pentium4 CPUs the FORCE_OVF flag is set then an NMI happens
on every event, which can generate a flood of NMIs. Clear it.
Reported-by: NVince Weaver <vweaver1@eecs.utk.edu>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Merge reason: pick up perf fixes
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This fixes the following build warning introduced by the
callchain rework:

  arch/x86/kernel/cpu/perf_event.c:1574: warning: ‘perf_callchain_entry_nmi’ defined but not used
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <1282718949.16443.75.camel@minggr.sh.intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

save_stack_trace() stores the instruction pointer, not the
function descriptor. On ppc64 the trace stack code currently
dereferences the instruction pointer and shows 8 bytes of
instructions in our backtraces:

 # cat /sys/kernel/debug/tracing/stack_trace
        Depth    Size   Location    (26 entries)
        -----    ----   --------
  0)     5424     112   0x6000000048000004
  1)     5312     160   0x60000000ebad01b0
  2)     5152     160   0x2c23000041c20030
  3)     4992     240   0x600000007c781b79
  4)     4752     160   0xe84100284800000c
  5)     4592     192   0x600000002fa30000
  6)     4400     256   0x7f1800347b7407e0
  7)     4144     208   0xe89f0108f87f0070
  8)     3936     272   0xe84100282fa30000

Since we aren't dealing with function descriptors, use %pS
instead of %pF to fix it:

 # cat /sys/kernel/debug/tracing/stack_trace
        Depth    Size   Location    (26 entries)
        -----    ----   --------
  0)     5424     112   ftrace_call+0x4/0x8
  1)     5312     160   .current_io_context+0x28/0x74
  2)     5152     160   .get_io_context+0x48/0xa0
  3)     4992     240   .cfq_set_request+0x94/0x4c4
  4)     4752     160   .elv_set_request+0x60/0x84
  5)     4592     192   .get_request+0x2d4/0x468
  6)     4400     256   .get_request_wait+0x7c/0x258
  7)     4144     208   .__make_request+0x49c/0x610
  8)     3936     272   .generic_make_request+0x390/0x434
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: rostedt@goodmis.org
Cc: fweisbec@gmail.com
LKML-Reference: <20100825013238.GE28360@kryten>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  watchdog: Don't throttle the watchdog
  tracing: Fix timer tracing

Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  mutex: Improve the scalability of optimistic spinning

pa-risc and ia64 have stacks that grow upwards. Check that
they do not run into other mappings. By making VM_GROWSUP
0x0 on architectures that do not ever use it, we can avoid
some unpleasant #ifdefs in check_stack_guard_page().
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When converting this to the new wait_for macro I inverted the wait
condition, which causes all sorts of problems.  So correct it to fix
several failures caused by the bad wait (flickering, bad output
detection, tearing, etc.).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
  [S390] fix tlb flushing vs. concurrent /proc accesses
  [S390] s390: fix build error (sys_execve)

We should pass the data to the data register.
Signed-off-by: NJianwei Yang <jianwei.yang@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It looks like there is an off-by-one error in one of your changes to
drivers/staging/rar_register/rar_register.c:
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This build bug triggers:

 drivers/built-in.o: In function `mantis_exit':
 (.text+0x377413): undefined reference to `ir_input_unregister'
 drivers/built-in.o: In function `mantis_input_init':
 (.text+0x3774ff): undefined reference to `__ir_input_register'

If MANTIS_CORE is enabled but IR_CORE is not. Add the correct
dependency.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  sparc64: Get rid of indirect p1275 PROM call buffer.
  sparc64: Fill a missing delay slot.
  sparc64: Make lock backoff really a NOP on UP builds.
  sparc64: simple microoptimizations for atomic functions
  sparc64: Make rwsems 64-bit.
  sparc64: Really fix atomic64_t interface types.

The tlb flushing code uses the mm_users field of the mm_struct to
decide if each page table entry needs to be flushed individually with
IPTE or if a global flush for the mm_struct is sufficient after all page
table updates have been done. The comment for mm_users says "How many
users with user space?" but the /proc code increases mm_users after it
found the process structure by pid without creating a new user process.
Which makes mm_users useless for the decision between the two tlb
flusing methods. The current code can be confused to not flush tlb
entries by a concurrent access to /proc files if e.g. a fork is in
progres. The solution for this problem is to make the tlb flushing
logic independent from the mm_users field.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (25 commits)
  powerpc: Fix config dependency problem with MPIC_U3_HT_IRQS
  via-pmu: Add compat_pmu_ioctl
  powerpc: Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
  powerpc/pci: Fix checking for child bridges in PCI code.
  powerpc: Fix typo in uImage target
  powerpc: Initialise paca->kstack before early_setup_secondary
  powerpc: Fix bogus it_blocksize in VIO iommu code
  powerpc: Inline ppc64_runlatch_off
  powerpc: Correct smt_enabled=X boot option for > 2 threads per core
  powerpc: Silence xics_migrate_irqs_away() during cpu offline
  powerpc: Silence __cpu_up() under normal operation
  powerpc: Re-enable preemption before cpu_die()
  powerpc/pci: Drop unnecessary null test
  powerpc/powermac: Drop unnecessary null test
  powerpc/powermac: Drop unnecessary of_node_put
  powerpc/kdump: Stop all other CPUs before running crash handlers
  powerpc/mm: Fix vsid_scrample typo
  powerpc: Use is_32bit_task() helper to test 32 bit binary
  powerpc: Export memstart_addr and kernstart_addr on ppc64
  powerpc: Make rwsem use "long" type
  ...

fix this build error:
arch/s390/kernel/process.c:272: error: conflicting types for 'sys_execve'
arch/s390/kernel/entry.h:45: error: previous declaration of 'sys_execve' was here
make[1]: *** [arch/s390/kernel/process.o] Error 1
make: *** [arch/s390/kernel] Error 2

introduced by d7627467Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6:
  Staging: sep: remove driver
  Staging: batman-adv: Don't write in not allocated packet_buff
  Staging: batman-adv: Don't use net_dev after dev_put
  Staging: batman-adv: Create batman_if only on register event
  Staging: batman-adv: fix own mac address detection
  Staging: batman-adv: always reply batman icmp packets with primary mac
  Staging: batman-adv: fix batman icmp originating from secondary interface
  Staging: batman-adv: unify orig_hash_lock spinlock handling to avoid deadlocks
  Staging: batman-adv: Fix merge of linus tree
  Staging: spectra: removes unused functions
  Staging: spectra: initializa lblk variable
  Staging: spectra: removes unused variable
  Staging: spectra: remove duplicate GLOB_VERSION definition
  Staging: spectra: don't use locked_ioctl, fix build
  Staging: use new REQ_FLUSH flag, fix build breakage
  Staging: spectra: removes q->prepare_flush_fn, fix build breakage

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
  68328serial: check return value of copy_*_user() instead of access_ok()
  synclink: add mutex_unlock() on error path
  rocket: add a mutex_unlock()
  ip2: return -EFAULT on copy_to_user errors
  ip2: remove unneeded NULL check
  serial: print early console device address in hex

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6:
  kobject_uevent: fix typo in comments
  firmware_class: fix typo in error path
  kobject: Break the kobject namespace defs into their own header

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (29 commits)
  ARM: imx: fix build failure concerning otg/ulpi
  USB: ftdi_sio: add product ID for Lenz LI-USB
  USB: adutux: fix misuse of return value of copy_to_user()
  USB: iowarrior: fix misuse of return value of copy_to_user()
  USB: xHCI: update ring dequeue pointer when process missed tds
  USB: xhci: Remove buggy assignment in next_trb()
  USB: ftdi_sio: Add ID for Ionics PlugComputer
  USB: serial: io_ti.c: don't return 0 if writing the download record failed
  USB: otg: twl4030: fix wrong assumption of starting state
  USB: gadget: Return -ENOMEM on memory allocation failure
  USB: gadget: fix composite kernel-doc warnings
  USB: ssu100: set tty_flags in ssu100_process_packet
  USB: ssu100: add disconnect function for ssu100
  USB: serial: export symbol usb_serial_generic_disconnect
  USB: ssu100: rework logic for TIOCMIWAIT
  USB: ssu100: add register parameter to ssu100_setregister
  USB: ssu100: remove duplicate #defines in ssu100
  USB: ssu100: refine process_packet in ssu100
  USB: ssu100: add locking for port private data in ssu100
  USB: r8a66597-udc: return -ENOMEM if kzalloc() fails
  ...

This is based upon a report by Meelis Roos showing that it's possible
that we'll try to fetch a property that is 32K in size with some
devices.  With the current fixed 3K buffer we use for moving data in
and out of the firmware during PROM calls, that simply won't work.

In fact, it will scramble random kernel data during bootup.

The reasoning behind the temporary buffer is entirely historical.  It
used to be the case that we had problems referencing dynamic kernel
memory (including the stack) early in the boot process before we
explicitly told the firwmare to switch us over to the kernel trap
table.

So what we did was always give the firmware buffers that were locked
into the main kernel image.

But we no longer have problems like that, so get rid of all of this
indirect bounce buffering.

Besides fixing Meelis's bug, this also makes the kernel data about 3K
smaller.

It was also discovered during these conversions that the
implementation of prom_retain() was completely wrong, so that was
fixed here as well.  Currently that interface is not in use.
Reported-by: NMeelis Roos <mroos@linux.ee>
Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

MPIC_U3_HT_IRQS is selected both by PPC_PMAC64 and PPC_MAPLE, but depends
on PPC_MAPLE, so a PPC_PMAC64-only config gets this warning:

warning: (PPC_PMAC64 && PPC_PMAC && POWER4 || PPC_MAPLE && PPC64 && PPC_BOOK3S) selects MPIC_U3_HT_IRQS which has unmet direct dependencies (PPC_MAPLE)

Fix that by removing the dependency on PPC_MAPLE.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The ioctls are actually compatible, but due to historical mistake the
numbers differ between 32bit and 64bit.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

pci_device_to_OF_node() can return null, and list_for_each_entry will
never enter the loop when dev is NULL, so it looks like this test is
a typo.
Reported-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit e32e78c5
(powerpc: fix build with make 3.82) introduced a
typo in uImage target and broke building uImage:

make: *** No rule to make target `uImage'.  Stop.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

As early setup calls down to slb_initialize(), we must have kstack
initialised before checking "should we add a bolted SLB entry for our kstack?"

Failing to do so means stack access requires an SLB miss exception to refill
an entry dynamically, if the stack isn't accessible via SLB(0) (kernel text
& static data).  It's not always allowable to take such a miss, and
intermittent crashes will result.

Primary CPUs don't have this issue; an SLB entry is not bolted for their
stack anyway (as that lives within SLB(0)).  This patch therefore only
affects the init of secondaries.
Signed-off-by: NMatt Evans <matt@ozlabs.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

When looking at some issues with the virtual ethernet driver I noticed
that TCE allocation was following a very strange pattern:

address 00e9000 length 2048
address 0409000 length 2048 <-----
address 0429000 length 2048
address 0449000 length 2048
address 0469000 length 2048
address 0489000 length 2048
address 04a9000 length 2048
address 04c9000 length 2048
address 04e9000 length 2048
address 4009000 length 2048 <-----
address 4029000 length 2048

Huge unexplained gaps in what should be an empty TCE table. It turns out
it_blocksize, the amount we want to align the next allocation to, was
c0000000fe903b20. Completely bogus.

Initialise it to something reasonable in the VIO IOMMU code, and use kzalloc
everywhere to protect against this when we next add a non compulsary
field to iommu code and forget to initialise it.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

I'm sick of seeing ppc64_runlatch_off in our profiles, so inline it
into the callers. To avoid a mess of circular includes I didn't add
it as an inline function.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The 'smt_enabled=X' boot option does not handle values of X > 2.
For Power 7 processors with smt modes of 0,1,2,3, and 4 this does
not work.  This patch allows the smt_enabled option to be set to
any value limited to a max equal to the number of threads per
core.
Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>