from:"Anton Blanchard"

Re: [PATCH v2 1/2] powerpc/drmem: accelerate memory_add_physaddr_to_nid() with LMB xarray

2020-07-22 Thread Anton Blanchard

Hi Scott,

I'm hitting this issue and Rick just pointed my at your patch. Any
chance we could get it upstream?

Thanks,
Anton

> On PowerPC, memory_add_physaddr_to_nid() uses a linear search to find
> an LMB matching the given address.  This scales very poorly when there
> are many LMBs.  The poor scaling cripples drmem_init() during boot:
> lmb_set_nid(), which calls memory_add_physaddr_to_nid(), is called for
> each LMB.
> 
> If we index each LMB in an xarray by its base address we can achieve
> O(log n) search during memory_add_physaddr_to_nid(), which scales much
> better.
> 
> For example, in the lab we have a 64TB P9 machine with 256MB LMBs.
> So, suring drmem_init() we instantiate 249854 LMBs.  On a vanilla
> kernel it completes drmem_init() in ~35 seconds with a soft lockup
> trace.  On the patched kernel it completes drmem_init() in ~0.5
> seconds.
> 
> Before:
> [   53.721639] drmem: initializing drmem v2
> [   80.604346] watchdog: BUG: soft lockup - CPU#65 stuck for 23s!
> [swapper/0:1] [   80.604377] Modules linked in:
> [   80.604389] CPU: 65 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc2+
> #4 [   80.604397] NIP:  c00a4980 LR: c00a4940 CTR:
>  [   80.604407] REGS: c0002dbff8493830 TRAP: 0901
> Not tainted  (5.6.0-rc2+) [   80.604412] MSR:  82009033
>   CR: 44000248  XER: 000d [
> 80.604431] CFAR: c00a4a38 IRQMASK: 0 [   80.604431] GPR00:
> c00a4940 c0002dbff8493ac0 c1904400 c0003cfede30 [
>   80.604431] GPR04:  c0f4095a
> 002f 1000 [   80.604431] GPR08:
> cbf7ecdb7fb8 cbf7ecc2d3c8 0008 c00c0002fdfb2001 [
>   80.604431] GPR12:  c0001e8ec200 [   80.604477]
> NIP [c00a4980] hot_add_scn_to_nid+0xa0/0x3e0 [   80.604486]
> LR [c00a4940] hot_add_scn_to_nid+0x60/0x3e0 [   80.604492]
> Call Trace: [   80.604498] [c0002dbff8493ac0] [c00a4940]
> hot_add_scn_to_nid+0x60/0x3e0 (unreliable) [   80.604509]
> [c0002dbff8493b20] [c0087c10]
> memory_add_physaddr_to_nid+0x20/0x60 [   80.604521]
> [c0002dbff8493b40] [c10d4880] drmem_init+0x25c/0x2f0 [
> 80.604530] [c0002dbff8493c10] [c0010154]
> do_one_initcall+0x64/0x2c0 [   80.604540] [c0002dbff8493ce0]
> [c10c4aa0] kernel_init_freeable+0x2d8/0x3a0 [   80.604550]
> [c0002dbff8493db0] [c0010824] kernel_init+0x2c/0x148 [
> 80.604560] [c0002dbff8493e20] [c000b648]
> ret_from_kernel_thread+0x5c/0x74 [   80.604567] Instruction dump: [
> 80.604574] 392918e8 e949 e90a000a e92a 80ea000c 1d080018
> 3908ffe8 7d094214 [   80.604586] 7fa94040 419d00dc e9490010 714a0088
> <2faa0008> 409e00ac e949 7fbe5040 [   89.047390] drmem: 249854
> LMB(s)
> 
> After:
> [   53.424702] drmem: initializing drmem v2
> [   53.898813] drmem: 249854 LMB(s)
> 
> lmb_set_nid() is called from dlpar_lmb_add() so this patch will also
> improve memory hot-add speeds on big machines.
> 
> Signed-off-by: Scott Cheloha 
> ---
>  arch/powerpc/include/asm/drmem.h |  1 +
>  arch/powerpc/mm/drmem.c  | 24 
>  arch/powerpc/mm/numa.c   | 29 ++---
>  3 files changed, 35 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/drmem.h
> b/arch/powerpc/include/asm/drmem.h index 3d76e1c388c2..90a5a9ad872b
> 100644 --- a/arch/powerpc/include/asm/drmem.h
> +++ b/arch/powerpc/include/asm/drmem.h
> @@ -88,6 +88,7 @@ static inline bool drmem_lmb_reserved(struct
> drmem_lmb *lmb) return lmb->flags & DRMEM_LMB_RESERVED;
>  }
>  
> +struct drmem_lmb *drmem_find_lmb_by_base_addr(u64 base_addr);
>  u64 drmem_lmb_memory_max(void);
>  void __init walk_drmem_lmbs(struct device_node *dn,
>   void (*func)(struct drmem_lmb *, const
> __be32 **)); diff --git a/arch/powerpc/mm/drmem.c
> b/arch/powerpc/mm/drmem.c index 44bfbdae920c..62cbe79e3860 100644
> --- a/arch/powerpc/mm/drmem.c
> +++ b/arch/powerpc/mm/drmem.c
> @@ -11,12 +11,31 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +static DEFINE_XARRAY(drmem_lmb_xa_base_addr);
>  static struct drmem_lmb_info __drmem_info;
>  struct drmem_lmb_info *drmem_info = &__drmem_info;
>  
> +static int drmem_cache_lmb_for_lookup(struct drmem_lmb *lmb)
> +{
> + void *ret;
> +
> + ret = xa_store(_lmb_xa_base_addr, lmb->base_addr, lmb,
> +GFP_KERNEL);
> + if (xa_is_err(ret))
> + return xa_err(ret);
> +
> + return 0;
> +}
> +
> +struct drmem_lmb *drmem_find_lmb_by_base_addr(u64 base_addr)
> +{
> + return xa_load(_lmb_xa_base_addr, base_addr);
> +}
> +
>  u64 drmem_lmb_memory_max(void)
>  {
>   struct drmem_lmb *last_lmb;
> @@ -364,6 +383,8 @@ static void __init init_drmem_v1_lmbs(const
> __be32 *prop) 
>   for_each_drmem_lmb(lmb) {
>   read_drconf_v1_cell(lmb, );
> + if (drmem_cache_lmb_for_lookup(lmb) != 0)
> +

Re: [PATCH] ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU

2020-06-25 Thread Anton Blanchard

Hi Nick,

> On a 144 thread system, `perf ftrace` takes about 20 seconds to start
> up, due to calling synchronize_rcu() for each CPU.
> 
>   cat /proc/108560/stack
> 0xc0003e7eb336f470
> __switch_to+0x2e0/0x480
> __wait_rcu_gp+0x20c/0x220
> synchronize_rcu+0x9c/0xc0
> ring_buffer_reset_cpu+0x88/0x2e0
> tracing_reset_online_cpus+0x84/0xe0
> tracing_open+0x1d4/0x1f0
> 
> On a system with 10x more threads, it starts to become an annoyance.
> 
> Batch these up so we disable all the per-cpu buffers first, then
> synchronize_rcu() once, then reset each of the buffers. This brings
> the time down to about 0.5s.

It's gone from somewhere more than 10 minutes (I gave up waiting) to
3 seconds. Nice work!

Tested-by: Anton Blanchard 

Thanks,
Anton

> Cc: Paul McKenney 
> Cc: Anton Blanchard 
> Cc: Steven Rostedt 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Nicholas Piggin 
> ---
>  include/linux/ring_buffer.h |  1 +
>  kernel/trace/ring_buffer.c  | 85
> +++-- kernel/trace/trace.c|
> 4 +- 3 files changed, 73 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
> index c76b2f3b3ac4..136ea0997e6d 100644
> --- a/include/linux/ring_buffer.h
> +++ b/include/linux/ring_buffer.h
> @@ -143,6 +143,7 @@ bool ring_buffer_iter_dropped(struct
> ring_buffer_iter *iter); unsigned long ring_buffer_size(struct
> trace_buffer *buffer, int cpu); 
>  void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu);
> +void ring_buffer_reset_online_cpus(struct trace_buffer *buffer);
>  void ring_buffer_reset(struct trace_buffer *buffer);
>  
>  #ifdef CONFIG_RING_BUFFER_ALLOW_SWAP
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index b8e1ca48be50..3f1fd02bd14a 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -270,6 +270,9 @@ EXPORT_SYMBOL_GPL(ring_buffer_event_data);
>  #define for_each_buffer_cpu(buffer, cpu) \
>   for_each_cpu(cpu, buffer->cpumask)
>  
> +#define for_each_online_buffer_cpu(buffer, cpu)  \
> + for_each_cpu_and(cpu, buffer->cpumask, cpu_online_mask)
> +
>  #define TS_SHIFT 27
>  #define TS_MASK  ((1ULL << TS_SHIFT) - 1)
>  #define TS_DELTA_TEST(~TS_MASK)
> @@ -4484,6 +4487,26 @@ rb_reset_cpu(struct ring_buffer_per_cpu
> *cpu_buffer) rb_head_page_activate(cpu_buffer);
>  }
>  
> +/* Must have disabled the cpu buffer then done a synchronize_rcu */
> +static void reset_disabled_cpu_buffer(struct ring_buffer_per_cpu
> *cpu_buffer) +{
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(_buffer->reader_lock, flags);
> +
> + if (RB_WARN_ON(cpu_buffer,
> local_read(_buffer->committing)))
> + goto out;
> +
> + arch_spin_lock(_buffer->lock);
> +
> + rb_reset_cpu(cpu_buffer);
> +
> + arch_spin_unlock(_buffer->lock);
> +
> + out:
> + raw_spin_unlock_irqrestore(_buffer->reader_lock, flags);
> +}
> +
>  /**
>   * ring_buffer_reset_cpu - reset a ring buffer per CPU buffer
>   * @buffer: The ring buffer to reset a per cpu buffer of
> @@ -4492,7 +4515,6 @@ rb_reset_cpu(struct ring_buffer_per_cpu
> *cpu_buffer) void ring_buffer_reset_cpu(struct trace_buffer *buffer,
> int cpu) {
>   struct ring_buffer_per_cpu *cpu_buffer =
> buffer->buffers[cpu];
> - unsigned long flags;
>  
>   if (!cpumask_test_cpu(cpu, buffer->cpumask))
>   return;
> @@ -4503,24 +4525,42 @@ void ring_buffer_reset_cpu(struct
> trace_buffer *buffer, int cpu) /* Make sure all commits have finished
> */ synchronize_rcu();
>  
> - raw_spin_lock_irqsave(_buffer->reader_lock, flags);
> + reset_disabled_cpu_buffer(cpu_buffer);
>  
> - if (RB_WARN_ON(cpu_buffer,
> local_read(_buffer->committing)))
> - goto out;
> + atomic_dec(_buffer->record_disabled);
> + atomic_dec(_buffer->resize_disabled);
> +}
> +EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
>  
> - arch_spin_lock(_buffer->lock);
> +/**
> + * ring_buffer_reset_cpu - reset a ring buffer per CPU buffer
> + * @buffer: The ring buffer to reset a per cpu buffer of
> + * @cpu: The CPU buffer to be reset
> + */
> +void ring_buffer_reset_online_cpus(struct trace_buffer *buffer)
> +{
> + struct ring_buffer_per_cpu *cpu_buffer;
> + int cpu;
>  
> - rb_reset_cpu(cpu_buffer);
> + for_each_online_buffer_cpu(buffer, cpu) {
> + cpu_buffer = buffer->buffers[cpu];
>  
> - arch_spin_unlock(_buffer->lock);
> + atomic_inc(_buffer->resiz

CFS bandwidth control hits hard lockup warnings

2018-12-03 Thread Anton Blanchard

Hi,

We are seeing hard lockup warnings caused by CFS bandwidth control code. The
test case below fails almost immediately on a reasonably large (144 thread)
POWER9 guest with:

watchdog: CPU 80 Hard LOCKUP
watchdog: CPU 80 TB:1134131922788, last heartbeat TB:1133207948315 (1804ms ago)
Modules linked in:
CPU: 80 PID: 0 Comm: swapper/80 Tainted: G L
4.20.0-rc4-00156-g94f371cb7394-dirty #98
NIP:  c018f618 LR: c0185174 CTR: c018f5f0
REGS: cfbbbd70 TRAP: 0100   Tainted: G L 
(4.20.0-rc4-00156-g94f371cb7394-dirty)
MSR:  80009033   CR: 28000222  XER: 
CFAR: c0002440 IRQMASK: 1
GPR00: c0185174 c03fef927610 c10bd500 c03fab1dbb80
GPR04: c03ffe2d3000 c018f5f0 c03ffe2d3000 0076e60d19fe
GPR08: c03fab1dbb80 0178 c03fa722f800 0001
GPR12: c018f5f0 cffb3700 c03fef927f90 
GPR16:  c0f8d468 0050 c004ace0
GPR20: c03ffe743260 2a61 0001 
GPR24: 0076e61c5aa0 3b9aca00  c017cdb0
GPR28: c03fc229 c03ffe2d3000 c018f5f0 c03fa74ca800
NIP [c018f618] tg_unthrottle_up+0x28/0xc0
LR [c0185174] walk_tg_tree_from+0x94/0x120
Call Trace:
[c03fef927610] [c03fe3ad5000] 0xc03fe3ad5000 (unreliable)
[c03fef927690] [c004b8ac] smp_muxed_ipi_message_pass+0x5c/0x70
[c03fef9276e0] [c019d828] unthrottle_cfs_rq+0xe8/0x300
[c03fef927770] [c019dc80] distribute_cfs_runtime+0x160/0x1d0
[c03fef927820] [c019e044] sched_cfs_period_timer+0x154/0x2f0
[c03fef9278a0] [c01f8fc0] __hrtimer_run_queues+0x180/0x430
[c03fef927920] [c01fa2a0] hrtimer_interrupt+0x110/0x300
[c03fef9279d0] [c00291d4] timer_interrupt+0x104/0x2e0
[c03fef927a30] [c0009028] decrementer_common+0x108/0x110

Adding CPUs, or adding empty cgroups makes the situation worse. We haven't
had a chance to dig deeper yet.

Note: The test case makes no attempt to clean up after itself and sometimes
takes my guest down :)

Thanks,
Anton
--

#!/bin/bash -e 

echo 1 > /proc/sys/kernel/nmi_watchdog
echo 1 > /proc/sys/kernel/watchdog_thresh

mkdir -p /sys/fs/cgroup/cpu/base_cgroup
echo 1000 > /sys/fs/cgroup/cpu/base_cgroup/cpu.cfs_period_us
echo 100 > /sys/fs/cgroup/cpu/base_cgroup/cpu.cfs_quota_us

# Create some empty cgroups
for i in $(seq 1 1024)
do
mkdir -p /sys/fs/cgroup/cpu/base_cgroup/$i
done

# Create some cgroups with a CPU soaker
for i in $(seq 1 144)
do
(while :; do :; done ) &
PID=$!
mkdir -p /sys/fs/cgroup/cpu/base_cgroup/$PID
echo $PID > /sys/fs/cgroup/cpu/base_cgroup/$PID/cgroup.procs
done

CFS bandwidth control hits hard lockup warnings

2018-12-03 Thread Anton Blanchard

Hi,

We are seeing hard lockup warnings caused by CFS bandwidth control code. The
test case below fails almost immediately on a reasonably large (144 thread)
POWER9 guest with:

watchdog: CPU 80 Hard LOCKUP
watchdog: CPU 80 TB:1134131922788, last heartbeat TB:1133207948315 (1804ms ago)
Modules linked in:
CPU: 80 PID: 0 Comm: swapper/80 Tainted: G L
4.20.0-rc4-00156-g94f371cb7394-dirty #98
NIP:  c018f618 LR: c0185174 CTR: c018f5f0
REGS: cfbbbd70 TRAP: 0100   Tainted: G L 
(4.20.0-rc4-00156-g94f371cb7394-dirty)
MSR:  80009033   CR: 28000222  XER: 
CFAR: c0002440 IRQMASK: 1
GPR00: c0185174 c03fef927610 c10bd500 c03fab1dbb80
GPR04: c03ffe2d3000 c018f5f0 c03ffe2d3000 0076e60d19fe
GPR08: c03fab1dbb80 0178 c03fa722f800 0001
GPR12: c018f5f0 cffb3700 c03fef927f90 
GPR16:  c0f8d468 0050 c004ace0
GPR20: c03ffe743260 2a61 0001 
GPR24: 0076e61c5aa0 3b9aca00  c017cdb0
GPR28: c03fc229 c03ffe2d3000 c018f5f0 c03fa74ca800
NIP [c018f618] tg_unthrottle_up+0x28/0xc0
LR [c0185174] walk_tg_tree_from+0x94/0x120
Call Trace:
[c03fef927610] [c03fe3ad5000] 0xc03fe3ad5000 (unreliable)
[c03fef927690] [c004b8ac] smp_muxed_ipi_message_pass+0x5c/0x70
[c03fef9276e0] [c019d828] unthrottle_cfs_rq+0xe8/0x300
[c03fef927770] [c019dc80] distribute_cfs_runtime+0x160/0x1d0
[c03fef927820] [c019e044] sched_cfs_period_timer+0x154/0x2f0
[c03fef9278a0] [c01f8fc0] __hrtimer_run_queues+0x180/0x430
[c03fef927920] [c01fa2a0] hrtimer_interrupt+0x110/0x300
[c03fef9279d0] [c00291d4] timer_interrupt+0x104/0x2e0
[c03fef927a30] [c0009028] decrementer_common+0x108/0x110

Adding CPUs, or adding empty cgroups makes the situation worse. We haven't
had a chance to dig deeper yet.

Note: The test case makes no attempt to clean up after itself and sometimes
takes my guest down :)

Thanks,
Anton
--

#!/bin/bash -e 

echo 1 > /proc/sys/kernel/nmi_watchdog
echo 1 > /proc/sys/kernel/watchdog_thresh

mkdir -p /sys/fs/cgroup/cpu/base_cgroup
echo 1000 > /sys/fs/cgroup/cpu/base_cgroup/cpu.cfs_period_us
echo 100 > /sys/fs/cgroup/cpu/base_cgroup/cpu.cfs_quota_us

# Create some empty cgroups
for i in $(seq 1 1024)
do
mkdir -p /sys/fs/cgroup/cpu/base_cgroup/$i
done

# Create some cgroups with a CPU soaker
for i in $(seq 1 144)
do
(while :; do :; done ) &
PID=$!
mkdir -p /sys/fs/cgroup/cpu/base_cgroup/$PID
echo $PID > /sys/fs/cgroup/cpu/base_cgroup/$PID/cgroup.procs
done

Re: [PATCH 1/2] ext4: fix warning about stack corruption

2017-08-22 Thread Anton Blanchard


> > Unfortunately it doesn't appear to work, at least with ppc64le
> > clang:
> >
> > fs/ext4/mballoc.c:2303:17: error: fields must have a constant size:
> > 'variable length array in structure' extension will never be
> > supported ext4_grpblk_t counters[blocksize_bits + 2];  
> 
> My fix for this is in the ext4/dev branch in linux-next, I hope it
> still makes it into v4.13.

Thanks Arnd, I see it now.

Anton

Re: [PATCH 1/2] ext4: fix warning about stack corruption

2017-08-22 Thread Anton Blanchard


> > Unfortunately it doesn't appear to work, at least with ppc64le
> > clang:
> >
> > fs/ext4/mballoc.c:2303:17: error: fields must have a constant size:
> > 'variable length array in structure' extension will never be
> > supported ext4_grpblk_t counters[blocksize_bits + 2];  
> 
> My fix for this is in the ext4/dev branch in linux-next, I hope it
> still makes it into v4.13.

Thanks Arnd, I see it now.

Anton

Re: [PATCH 1/2] ext4: fix warning about stack corruption

2017-08-22 Thread Anton Blanchard

Hi Arnd,

> After commit 62d1034f53e3 ("fortify: use WARN instead of BUG for
> now"), we get a warning about possible stack overflow from a memcpy
> that was not strictly bounded to the size of the local variable:
> 
> inlined from 'ext4_mb_seq_groups_show' at
> fs/ext4/mballoc.c:2322:2: include/linux/string.h:309:9: error:
> '__builtin_memcpy': writing between 161 and 1116 bytes into a region
> of size 160 overflows the destination [-Werror=stringop-overflow=]
> 
> We actually had a bug here that would have been found by the warning,
> but it was already fixed last year in commit 30a9d7afe70e ("ext4: fix
> stack memory corruption with 64k block size").
> 
> This replaces the fixed-length structure on the stack with a
> variable-length structure, using the correct upper bound that tells
> the compiler that everything is really fine here. I also change the
> loop count to check for the same upper bound for consistency, but the
> existing code is already correct here.
> 
> Note that while clang won't allow certain kinds of variable-length
> arrays in structures, this particular instance is fine, as the array
> is at the end of the structure, and the size is strictly bounded.

Unfortunately it doesn't appear to work, at least with ppc64le clang:

fs/ext4/mballoc.c:2303:17: error: fields must have a constant size: 'variable 
length array in structure' extension will never be supported
ext4_grpblk_t counters[blocksize_bits + 2];

Anton

Re: [PATCH 1/2] ext4: fix warning about stack corruption

2017-08-22 Thread Anton Blanchard

Hi Arnd,

> After commit 62d1034f53e3 ("fortify: use WARN instead of BUG for
> now"), we get a warning about possible stack overflow from a memcpy
> that was not strictly bounded to the size of the local variable:
> 
> inlined from 'ext4_mb_seq_groups_show' at
> fs/ext4/mballoc.c:2322:2: include/linux/string.h:309:9: error:
> '__builtin_memcpy': writing between 161 and 1116 bytes into a region
> of size 160 overflows the destination [-Werror=stringop-overflow=]
> 
> We actually had a bug here that would have been found by the warning,
> but it was already fixed last year in commit 30a9d7afe70e ("ext4: fix
> stack memory corruption with 64k block size").
> 
> This replaces the fixed-length structure on the stack with a
> variable-length structure, using the correct upper bound that tells
> the compiler that everything is really fine here. I also change the
> loop count to check for the same upper bound for consistency, but the
> existing code is already correct here.
> 
> Note that while clang won't allow certain kinds of variable-length
> arrays in structures, this particular instance is fine, as the array
> is at the end of the structure, and the size is strictly bounded.

Unfortunately it doesn't appear to work, at least with ppc64le clang:

fs/ext4/mballoc.c:2303:17: error: fields must have a constant size: 'variable 
length array in structure' extension will never be supported
ext4_grpblk_t counters[blocksize_bits + 2];

Anton

Re: [PATCH] powerpc: Tweak copy selection parameter in __copy_tofrom_user_power7()

2017-05-18 Thread Anton Blanchard

Hi Andrew,

> Experiments with the netperf benchmark indicated that the size
> selecting VMX-based copies in __copy_tofrom_user_power7() was
> suboptimal on POWER8. Measurements showed that parity was in the
> neighbourhood of 3328 bytes, rather than greater than 4096. The
> change gives a 1.5-2.0% improvement in performance for 4096-byte
> buffers, reducing the relative time spent in
> __copy_tofrom_user_power7() from approximately 7% to approximately 5%
> in the TCP_RR benchmark.

Nice work! All our context switch optimisations we've made over
the last year has likely moved the break even point for this.

Acked-by: Anton Blanchard <an...@samba.org>

Anton

> Signed-off-by: Andrew Jeffery <and...@aj.id.au>
> ---
>  arch/powerpc/lib/copyuser_power7.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/lib/copyuser_power7.S
> b/arch/powerpc/lib/copyuser_power7.S index a24b4039352c..706b7cc19846
> 100644 --- a/arch/powerpc/lib/copyuser_power7.S
> +++ b/arch/powerpc/lib/copyuser_power7.S
> @@ -82,14 +82,14 @@
>  _GLOBAL(__copy_tofrom_user_power7)
>  #ifdef CONFIG_ALTIVEC
>   cmpldi  r5,16
> - cmpldi  cr1,r5,4096
> + cmpldi  cr1,r5,3328
>  
>   std r3,-STACKFRAMESIZE+STK_REG(R31)(r1)
>   std r4,-STACKFRAMESIZE+STK_REG(R30)(r1)
>   std r5,-STACKFRAMESIZE+STK_REG(R29)(r1)
>  
>   blt .Lshort_copy
> - bgt cr1,.Lvmx_copy
> + bge cr1,.Lvmx_copy
>  #else
>   cmpldi  r5,16
>

Re: [PATCH] powerpc: Tweak copy selection parameter in __copy_tofrom_user_power7()

2017-05-18 Thread Anton Blanchard

Hi Andrew,

> Experiments with the netperf benchmark indicated that the size
> selecting VMX-based copies in __copy_tofrom_user_power7() was
> suboptimal on POWER8. Measurements showed that parity was in the
> neighbourhood of 3328 bytes, rather than greater than 4096. The
> change gives a 1.5-2.0% improvement in performance for 4096-byte
> buffers, reducing the relative time spent in
> __copy_tofrom_user_power7() from approximately 7% to approximately 5%
> in the TCP_RR benchmark.

Nice work! All our context switch optimisations we've made over
the last year has likely moved the break even point for this.

Acked-by: Anton Blanchard 

Anton

> Signed-off-by: Andrew Jeffery 
> ---
>  arch/powerpc/lib/copyuser_power7.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/lib/copyuser_power7.S
> b/arch/powerpc/lib/copyuser_power7.S index a24b4039352c..706b7cc19846
> 100644 --- a/arch/powerpc/lib/copyuser_power7.S
> +++ b/arch/powerpc/lib/copyuser_power7.S
> @@ -82,14 +82,14 @@
>  _GLOBAL(__copy_tofrom_user_power7)
>  #ifdef CONFIG_ALTIVEC
>   cmpldi  r5,16
> - cmpldi  cr1,r5,4096
> + cmpldi  cr1,r5,3328
>  
>   std r3,-STACKFRAMESIZE+STK_REG(R31)(r1)
>   std r4,-STACKFRAMESIZE+STK_REG(R30)(r1)
>   std r5,-STACKFRAMESIZE+STK_REG(R29)(r1)
>  
>   blt .Lshort_copy
> - bgt cr1,.Lvmx_copy
> + bge cr1,.Lvmx_copy
>  #else
>   cmpldi  r5,16
>

[PATCH] [media] ir-spi: Fix issues with lirc API

2017-05-07 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

The ir-spi driver has 2 issues which prevents it from working with
lirc:

1. The ir-spi driver uses 16 bits of SPI data to create one cycle of
the waveform. As such our SPI clock needs to be 16x faster than the
carrier frequency.

The driver is inconsistent in how it currently handles this. It
initializes it to the carrier frequency:

But the commit message has some example code which initialises it
to 16x the carrier frequency:

val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, );

To maintain compatibility with lirc, always do the frequency adjustment
in the driver.

2. lirc presents pulses in microseconds, but the ir-spi driver treats
them as cycles of the carrier. Similar to other lirc drivers, do the
conversion with DIV_ROUND_CLOSEST().

Fixes: fe052da49201 ("[media] rc: add support for IR LEDs driven through SPI")
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard <an...@samba.org>
---
 drivers/media/rc/ir-spi.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
index c8863f36686a..f39cf8cb639f 100644
--- a/drivers/media/rc/ir-spi.c
+++ b/drivers/media/rc/ir-spi.c
@@ -57,10 +57,13 @@ static int ir_spi_tx(struct rc_dev *dev,
 
/* convert the pulse/space signal to raw binary signal */
for (i = 0; i < count; i++) {
+   unsigned int periods;
int j;
u16 val = ((i + 1) % 2) ? idata->pulse : idata->space;
 
-   if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+   periods = DIV_ROUND_CLOSEST(buffer[i] * idata->freq, 100);
+
+   if (len + periods >= IR_SPI_MAX_BUFSIZE)
return -EINVAL;
 
/*
@@ -69,13 +72,13 @@ static int ir_spi_tx(struct rc_dev *dev,
 * contain a space duration.
 */
val = (i % 2) ? idata->space : idata->pulse;
-   for (j = 0; j < buffer[i]; j++)
+   for (j = 0; j < periods; j++)
idata->tx_buf[len++] = val;
}
 
memset(, 0, sizeof(xfer));
 
-   xfer.speed_hz = idata->freq;
+   xfer.speed_hz = idata->freq * 16;
xfer.len = len * sizeof(*idata->tx_buf);
xfer.tx_buf = idata->tx_buf;
 
-- 
2.11.0

[PATCH] [media] ir-spi: Fix issues with lirc API

2017-05-07 Thread Anton Blanchard

From: Anton Blanchard 

The ir-spi driver has 2 issues which prevents it from working with
lirc:

1. The ir-spi driver uses 16 bits of SPI data to create one cycle of
the waveform. As such our SPI clock needs to be 16x faster than the
carrier frequency.

The driver is inconsistent in how it currently handles this. It
initializes it to the carrier frequency:

But the commit message has some example code which initialises it
to 16x the carrier frequency:

val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, );

To maintain compatibility with lirc, always do the frequency adjustment
in the driver.

2. lirc presents pulses in microseconds, but the ir-spi driver treats
them as cycles of the carrier. Similar to other lirc drivers, do the
conversion with DIV_ROUND_CLOSEST().

Fixes: fe052da49201 ("[media] rc: add support for IR LEDs driven through SPI")
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard 
---
 drivers/media/rc/ir-spi.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
index c8863f36686a..f39cf8cb639f 100644
--- a/drivers/media/rc/ir-spi.c
+++ b/drivers/media/rc/ir-spi.c
@@ -57,10 +57,13 @@ static int ir_spi_tx(struct rc_dev *dev,
 
/* convert the pulse/space signal to raw binary signal */
for (i = 0; i < count; i++) {
+   unsigned int periods;
int j;
u16 val = ((i + 1) % 2) ? idata->pulse : idata->space;
 
-   if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+   periods = DIV_ROUND_CLOSEST(buffer[i] * idata->freq, 100);
+
+   if (len + periods >= IR_SPI_MAX_BUFSIZE)
return -EINVAL;
 
/*
@@ -69,13 +72,13 @@ static int ir_spi_tx(struct rc_dev *dev,
 * contain a space duration.
 */
val = (i % 2) ? idata->space : idata->pulse;
-   for (j = 0; j < buffer[i]; j++)
+   for (j = 0; j < periods; j++)
idata->tx_buf[len++] = val;
}
 
memset(, 0, sizeof(xfer));
 
-   xfer.speed_hz = idata->freq;
+   xfer.speed_hz = idata->freq * 16;
xfer.len = len * sizeof(*idata->tx_buf);
xfer.tx_buf = idata->tx_buf;
 
-- 
2.11.0

Re: [PATCH] Enabled pstore write for powerpc

2017-04-27 Thread Anton Blanchard

Hi Ankit,

> After commit c950fd6f201a kernel registers pstore write based on flag
> set. Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG)
> is not set for powerpc architecture. On panic, kernel doesn't write
> message to /fs/pstore/dmesg*(Entry doesn't gets created at all).
> 
> This patch enables pstore write for powerpc architecture by setting
> PSTORE_FLAGS_DMESG flag.
> 
> Fixes:c950fd6f201a pstore: Split pstore fragile flags

Ouch! We've used pstore to shoot customer bugs, so we should also mark
this for stable. Looks like 4.9 onwards?

Anton

> Signed-off-by: Ankit Kumar 
> ---
> 
>  arch/powerpc/kernel/nvram_64.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/kernel/nvram_64.c
> b/arch/powerpc/kernel/nvram_64.c index d5e2b83..021db31 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -561,6 +561,7 @@ static ssize_t nvram_pstore_read(u64 *id, enum
> pstore_type_id *type, static struct pstore_info nvram_pstore_info = {
>   .owner = THIS_MODULE,
>   .name = "nvram",
> + .flags = PSTORE_FLAGS_DMESG,
>   .open = nvram_pstore_open,
>   .read = nvram_pstore_read,
>   .write = nvram_pstore_write,

Re: [PATCH] Enabled pstore write for powerpc

2017-04-27 Thread Anton Blanchard

Hi Ankit,

> After commit c950fd6f201a kernel registers pstore write based on flag
> set. Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG)
> is not set for powerpc architecture. On panic, kernel doesn't write
> message to /fs/pstore/dmesg*(Entry doesn't gets created at all).
> 
> This patch enables pstore write for powerpc architecture by setting
> PSTORE_FLAGS_DMESG flag.
> 
> Fixes:c950fd6f201a pstore: Split pstore fragile flags

Ouch! We've used pstore to shoot customer bugs, so we should also mark
this for stable. Looks like 4.9 onwards?

Anton

> Signed-off-by: Ankit Kumar 
> ---
> 
>  arch/powerpc/kernel/nvram_64.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/kernel/nvram_64.c
> b/arch/powerpc/kernel/nvram_64.c index d5e2b83..021db31 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -561,6 +561,7 @@ static ssize_t nvram_pstore_read(u64 *id, enum
> pstore_type_id *type, static struct pstore_info nvram_pstore_info = {
>   .owner = THIS_MODULE,
>   .name = "nvram",
> + .flags = PSTORE_FLAGS_DMESG,
>   .open = nvram_pstore_open,
>   .read = nvram_pstore_read,
>   .write = nvram_pstore_write,

Re: [PATCH] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

2017-04-10 Thread Anton Blanchard

Hi Ravi,

> If we set a kprobe on a 'stdu' instruction on powerpc64, we see a
> kernel OOPS:

Ouch! We should mark this for stable.

Anton

Re: [PATCH] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

2017-04-10 Thread Anton Blanchard

Hi Ravi,

> If we set a kprobe on a 'stdu' instruction on powerpc64, we see a
> kernel OOPS:

Ouch! We should mark this for stable.

Anton

Re: 5-level pagetable patches break ppc64le

2017-03-13 Thread Anton Blanchard

Hi Kirill,

> > My ppc64le boot tests stopped working as of commit c2febafc6773
> > ("mm: convert generic code to 5-level paging")
> > 
> > We hang part way during boot, just before bringing up the network. I
> > haven't had a chance to narrow it down yet.  
> 
> Please check if patch by this link helps:
> 
> http://lkml.kernel.org/r/20170313052213.11411-1-kirill.shute...@linux.intel.com

It does fix the ppc64le boot hangs, thanks.

Tested-by: Anton Blanchard <an...@samba.org>

Anton

Re: 5-level pagetable patches break ppc64le

2017-03-13 Thread Anton Blanchard

Hi Kirill,

> > My ppc64le boot tests stopped working as of commit c2febafc6773
> > ("mm: convert generic code to 5-level paging")
> > 
> > We hang part way during boot, just before bringing up the network. I
> > haven't had a chance to narrow it down yet.  
> 
> Please check if patch by this link helps:
> 
> http://lkml.kernel.org/r/20170313052213.11411-1-kirill.shute...@linux.intel.com

It does fix the ppc64le boot hangs, thanks.

Tested-by: Anton Blanchard 

Anton

5-level pagetable patches break ppc64le

2017-03-13 Thread Anton Blanchard

Hi,

My ppc64le boot tests stopped working as of commit c2febafc6773 ("mm:
convert generic code to 5-level paging")

We hang part way during boot, just before bringing up the network. I
haven't had a chance to narrow it down yet.

Anton

5-level pagetable patches break ppc64le

2017-03-13 Thread Anton Blanchard

Hi,

My ppc64le boot tests stopped working as of commit c2febafc6773 ("mm:
convert generic code to 5-level paging")

We hang part way during boot, just before bringing up the network. I
haven't had a chance to narrow it down yet.

Anton

[tip:perf/urgent] perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

2017-03-01 Thread tip-bot for Anton Blanchard

Commit-ID:  6b0b7551428e4caae1e2c023a529465a9a9ae2d4
Gitweb: http://git.kernel.org/tip/6b0b7551428e4caae1e2c023a529465a9a9ae2d4
Author: Anton Blanchard <an...@samba.org>
AuthorDate: Thu, 16 Feb 2017 17:00:50 +1100
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Wed, 1 Mar 2017 10:26:39 +0100

perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS.

Consistently use the plurals.

Signed-off-by: Anton Blanchard <an...@samba.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: a...@kernel.org
Cc: alexander.shish...@linux.intel.com
Cc: da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170216060050.20866-1-an...@ozlabs.org
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 Documentation/trace/kprobetrace.txt |  2 +-
 Documentation/trace/uprobetracer.txt|  2 +-
 arch/powerpc/configs/85xx/kmp204x_defconfig |  2 +-
 arch/s390/configs/default_defconfig |  2 +-
 arch/s390/configs/gcov_defconfig|  2 +-
 arch/s390/configs/performance_defconfig |  2 +-
 arch/s390/defconfig |  2 +-
 kernel/trace/Kconfig|  6 +++---
 kernel/trace/Makefile   |  4 ++--
 kernel/trace/trace.c| 10 +-
 kernel/trace/trace_probe.h  |  4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index e4991fb..41ef9d8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for 
__kprobes
 functions). Unlike the Tracepoint based event, this can be added and removed
 dynamically, on the fly.
 
-To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
 
 Similar to the events tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index fa7b680..bf526a7c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -7,7 +7,7 @@
 Overview
 
 Uprobe based trace events are similar to kprobe based trace events.
-To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y.
 
 Similar to the kprobe-event tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig 
b/arch/powerpc/configs/85xx/kmp204x_defconfig
index a60..34a4da2 100644
--- a/arch/powerpc/configs/85xx/kmp204x_defconfig
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_SCHEDSTATS=y
 CONFIG_RCU_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_MD4=y
diff --git a/arch/s390/configs/default_defconfig 
b/arch/s390/configs/default_defconfig
index 143b1e0..4b176fe 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index f05d2d6..0de46cc 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/performance_defconfig 
b/arch/s390/configs/performance_defconfig
index 2358bf3..e167557 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/defconfig

[tip:perf/urgent] perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

2017-03-01 Thread tip-bot for Anton Blanchard

Commit-ID:  6b0b7551428e4caae1e2c023a529465a9a9ae2d4
Gitweb: http://git.kernel.org/tip/6b0b7551428e4caae1e2c023a529465a9a9ae2d4
Author: Anton Blanchard 
AuthorDate: Thu, 16 Feb 2017 17:00:50 +1100
Committer:  Ingo Molnar 
CommitDate: Wed, 1 Mar 2017 10:26:39 +0100

perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS.

Consistently use the plurals.

Signed-off-by: Anton Blanchard 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@kernel.org
Cc: alexander.shish...@linux.intel.com
Cc: da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170216060050.20866-1-an...@ozlabs.org
Signed-off-by: Ingo Molnar 
---
 Documentation/trace/kprobetrace.txt |  2 +-
 Documentation/trace/uprobetracer.txt|  2 +-
 arch/powerpc/configs/85xx/kmp204x_defconfig |  2 +-
 arch/s390/configs/default_defconfig |  2 +-
 arch/s390/configs/gcov_defconfig|  2 +-
 arch/s390/configs/performance_defconfig |  2 +-
 arch/s390/defconfig |  2 +-
 kernel/trace/Kconfig|  6 +++---
 kernel/trace/Makefile   |  4 ++--
 kernel/trace/trace.c| 10 +-
 kernel/trace/trace_probe.h  |  4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index e4991fb..41ef9d8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for 
__kprobes
 functions). Unlike the Tracepoint based event, this can be added and removed
 dynamically, on the fly.
 
-To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
 
 Similar to the events tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index fa7b680..bf526a7c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -7,7 +7,7 @@
 Overview
 
 Uprobe based trace events are similar to kprobe based trace events.
-To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y.
 
 Similar to the kprobe-event tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig 
b/arch/powerpc/configs/85xx/kmp204x_defconfig
index a60..34a4da2 100644
--- a/arch/powerpc/configs/85xx/kmp204x_defconfig
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_SCHEDSTATS=y
 CONFIG_RCU_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_MD4=y
diff --git a/arch/s390/configs/default_defconfig 
b/arch/s390/configs/default_defconfig
index 143b1e0..4b176fe 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index f05d2d6..0de46cc 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/performance_defconfig 
b/arch/s390/configs/performance_defconfig
index 2358bf3..e167557 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index 68bfd09..97189db 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -179,7 +179,7 @@ CONFIG_FTRACE_SYSCALLS=y
 CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y

Re: [PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

2017-02-26 Thread Anton Blanchard

Hi Gautham,

> +handle_esl_ec_set:

Unless we want to expose this to things like perf, we might want to
make it a local label (eg .Lxx)

Anton

Re: [PATCH] powernv:idle: Fix bug due to labeling ambiguity in power_enter_stop

2017-02-26 Thread Anton Blanchard

Hi Gautham,

> +handle_esl_ec_set:

Unless we want to expose this to things like perf, we might want to
make it a local label (eg .Lxx)

Anton

[PATCH] perf: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

2017-02-15 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently
use the plurals.

Signed-off-by: Anton Blanchard <an...@samba.org>
---
 Documentation/trace/kprobetrace.txt |  2 +-
 Documentation/trace/uprobetracer.txt|  2 +-
 arch/powerpc/configs/85xx/kmp204x_defconfig |  2 +-
 arch/s390/configs/default_defconfig |  2 +-
 arch/s390/configs/gcov_defconfig|  2 +-
 arch/s390/configs/performance_defconfig |  2 +-
 arch/s390/defconfig |  2 +-
 kernel/trace/Kconfig|  6 +++---
 kernel/trace/Makefile   |  4 ++--
 kernel/trace/trace.c| 10 +-
 kernel/trace/trace_probe.h  |  4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index e4991fb..41ef9d8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for 
__kprobes
 functions). Unlike the Tracepoint based event, this can be added and removed
 dynamically, on the fly.
 
-To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
 
 Similar to the events tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index fa7b680..bf526a7c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -7,7 +7,7 @@
 Overview
 
 Uprobe based trace events are similar to kprobe based trace events.
-To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y.
 
 Similar to the kprobe-event tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig 
b/arch/powerpc/configs/85xx/kmp204x_defconfig
index a60..34a4da2 100644
--- a/arch/powerpc/configs/85xx/kmp204x_defconfig
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_SCHEDSTATS=y
 CONFIG_RCU_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_MD4=y
diff --git a/arch/s390/configs/default_defconfig 
b/arch/s390/configs/default_defconfig
index e0097536..53d7cbb 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index f05d2d6..0de46cc 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/performance_defconfig 
b/arch/s390/configs/performance_defconfig
index 2cf8734..e77f0dc 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index d00e368..0732a7f 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -179,7 +179,7 @@ CONFIG_FTRACE_SYSCALLS=y
 CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
 CONFIG_KPROBES_SANITY_TEST=y
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index d503800..d4a06e7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -429,7 +429,7 @@ config BLK_DEV_IO_TRACE
 
  If unsure, say N.
 
-config KPROBE_EVENT
+config KPROBE_EVENTS
depends on KPROBES
depends on HAVE_REGS_AND_STACK_ACCESS_API
bool "Enable kprobes-based dynamic events"
@@ -447,7 +447,7 @@ config KPROBE_EVENT
  This option is also required by perf-probe subcommand of perf tools.
  If you want to use perf tools, this option is strongly recommended.
 
-config UPROBE_EVENT

[PATCH] perf: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS

2017-02-15 Thread Anton Blanchard

From: Anton Blanchard 

We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently
use the plurals.

Signed-off-by: Anton Blanchard 
---
 Documentation/trace/kprobetrace.txt |  2 +-
 Documentation/trace/uprobetracer.txt|  2 +-
 arch/powerpc/configs/85xx/kmp204x_defconfig |  2 +-
 arch/s390/configs/default_defconfig |  2 +-
 arch/s390/configs/gcov_defconfig|  2 +-
 arch/s390/configs/performance_defconfig |  2 +-
 arch/s390/defconfig |  2 +-
 kernel/trace/Kconfig|  6 +++---
 kernel/trace/Makefile   |  4 ++--
 kernel/trace/trace.c| 10 +-
 kernel/trace/trace_probe.h  |  4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/trace/kprobetrace.txt 
b/Documentation/trace/kprobetrace.txt
index e4991fb..41ef9d8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for 
__kprobes
 functions). Unlike the Tracepoint based event, this can be added and removed
 dynamically, on the fly.
 
-To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
 
 Similar to the events tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index fa7b680..bf526a7c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -7,7 +7,7 @@
 Overview
 
 Uprobe based trace events are similar to kprobe based trace events.
-To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y.
 
 Similar to the kprobe-event tracer, this doesn't need to be activated via
 current_tracer. Instead of that, add probe points via
diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig 
b/arch/powerpc/configs/85xx/kmp204x_defconfig
index a60..34a4da2 100644
--- a/arch/powerpc/configs/85xx/kmp204x_defconfig
+++ b/arch/powerpc/configs/85xx/kmp204x_defconfig
@@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_SCHEDSTATS=y
 CONFIG_RCU_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_MD4=y
diff --git a/arch/s390/configs/default_defconfig 
b/arch/s390/configs/default_defconfig
index e0097536..53d7cbb 100644
--- a/arch/s390/configs/default_defconfig
+++ b/arch/s390/configs/default_defconfig
@@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig
index f05d2d6..0de46cc 100644
--- a/arch/s390/configs/gcov_defconfig
+++ b/arch/s390/configs/gcov_defconfig
@@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/configs/performance_defconfig 
b/arch/s390/configs/performance_defconfig
index 2cf8734..e77f0dc 100644
--- a/arch/s390/configs/performance_defconfig
+++ b/arch/s390/configs/performance_defconfig
@@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y
 CONFIG_FTRACE_SYSCALLS=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_HIST_TRIGGERS=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index d00e368..0732a7f 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -179,7 +179,7 @@ CONFIG_FTRACE_SYSCALLS=y
 CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
 CONFIG_STACK_TRACER=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENT=y
+CONFIG_UPROBE_EVENTS=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_TRACE_ENUM_MAP_FILE=y
 CONFIG_KPROBES_SANITY_TEST=y
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index d503800..d4a06e7 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -429,7 +429,7 @@ config BLK_DEV_IO_TRACE
 
  If unsure, say N.
 
-config KPROBE_EVENT
+config KPROBE_EVENTS
depends on KPROBES
depends on HAVE_REGS_AND_STACK_ACCESS_API
bool "Enable kprobes-based dynamic events"
@@ -447,7 +447,7 @@ config KPROBE_EVENT
  This option is also required by perf-probe subcommand of perf tools.
  If you want to use perf tools, this option is strongly recommended.
 
-config UPROBE_EVENT
+config UPROBE_EVENTS
bool "Enabl

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

2017-02-15 Thread Anton Blanchard

Hi Ingo,

> So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
> CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
> CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all
> plural.
> 
> I didn't notice the misnomer when merging these bits.

Ok, patch to follow.

Anton

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

2017-02-15 Thread Anton Blanchard

Hi Ingo,

> So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
> CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
> CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all
> plural.
> 
> I didn't notice the misnomer when merging these bits.

Ok, patch to follow.

Anton

[PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

2017-02-12 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT
and CONFIG_UPROBE_EVENT.

Signed-off-by: Anton Blanchard <an...@samba.org>
---
 arch/sparc/configs/sparc64_defconfig | 2 +-
 tools/perf/util/probe-file.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/configs/sparc64_defconfig 
b/arch/sparc/configs/sparc64_defconfig
index b2e650d..f912fd1 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -213,7 +213,7 @@ CONFIG_SCHEDSTATS=y
 # CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SYSCTL_SYSCALL_CHECK=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENTS=y
+CONFIG_UPROBE_EVENT=y
 CONFIG_KEYS=y
 CONFIG_CRYPTO_NULL=m
 CONFIG_CRYPTO_TEST=m
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 436b647..6c74391 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -38,9 +38,9 @@ static void print_open_warning(int err, bool uprobe)
const char *config;
 
if (uprobe)
-   config = "CONFIG_UPROBE_EVENTS";
+   config = "CONFIG_UPROBE_EVENT";
else
-   config = "CONFIG_KPROBE_EVENTS";
+   config = "CONFIG_KPROBE_EVENT";
 
pr_warning("%cprobe_events file does not exist"
   " - please rebuild kernel with %s.\n",
@@ -59,8 +59,8 @@ static void print_both_open_warning(int kerr, int uerr)
if (kerr == -ENOTSUP && uerr == -ENOTSUP)
pr_warning("Tracefs or debugfs is not mounted.\n");
else if (kerr == -ENOENT && uerr == -ENOENT)
-   pr_warning("Please rebuild kernel with CONFIG_KPROBE_EVENTS "
-  "or/and CONFIG_UPROBE_EVENTS.\n");
+   pr_warning("Please rebuild kernel with CONFIG_KPROBE_EVENT "
+  "or/and CONFIG_UPROBE_EVENT.\n");
else {
char sbuf[STRERR_BUFSIZE];
pr_warning("Failed to open kprobe events: %s.\n",
-- 
2.9.3

[PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

2017-02-12 Thread Anton Blanchard

From: Anton Blanchard 

Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT
and CONFIG_UPROBE_EVENT.

Signed-off-by: Anton Blanchard 
---
 arch/sparc/configs/sparc64_defconfig | 2 +-
 tools/perf/util/probe-file.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/configs/sparc64_defconfig 
b/arch/sparc/configs/sparc64_defconfig
index b2e650d..f912fd1 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -213,7 +213,7 @@ CONFIG_SCHEDSTATS=y
 # CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SYSCTL_SYSCALL_CHECK=y
 CONFIG_BLK_DEV_IO_TRACE=y
-CONFIG_UPROBE_EVENTS=y
+CONFIG_UPROBE_EVENT=y
 CONFIG_KEYS=y
 CONFIG_CRYPTO_NULL=m
 CONFIG_CRYPTO_TEST=m
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 436b647..6c74391 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -38,9 +38,9 @@ static void print_open_warning(int err, bool uprobe)
const char *config;
 
if (uprobe)
-   config = "CONFIG_UPROBE_EVENTS";
+   config = "CONFIG_UPROBE_EVENT";
else
-   config = "CONFIG_KPROBE_EVENTS";
+   config = "CONFIG_KPROBE_EVENT";
 
pr_warning("%cprobe_events file does not exist"
   " - please rebuild kernel with %s.\n",
@@ -59,8 +59,8 @@ static void print_both_open_warning(int kerr, int uerr)
if (kerr == -ENOTSUP && uerr == -ENOTSUP)
pr_warning("Tracefs or debugfs is not mounted.\n");
else if (kerr == -ENOENT && uerr == -ENOENT)
-   pr_warning("Please rebuild kernel with CONFIG_KPROBE_EVENTS "
-  "or/and CONFIG_UPROBE_EVENTS.\n");
+   pr_warning("Please rebuild kernel with CONFIG_KPROBE_EVENT "
+  "or/and CONFIG_UPROBE_EVENT.\n");
else {
char sbuf[STRERR_BUFSIZE];
pr_warning("Failed to open kprobe events: %s.\n",
-- 
2.9.3

Re: llist code relies on undefined behaviour, upsets llvm/clang

2017-01-16 Thread Anton Blanchard

Hi Peter,

> Last I checked I couldn't build a x86_64 kernel with llvm. So no, not
> something I've ever ran into.
> 
> Also, I would argue that this is broken in llvm, the kernel very much
> relies on things like this all over the place. Sure, we're way outside
> of what the C language spec says, but who bloody cares ;-)

True, but is there anything preventing gcc from implementing this
optimisation in the future? If we are relying on undefined behaviour we
should have a -fno-strict-* option to cover it.

> If llvm wants to compile the kernel, it needs to learn the C dialect
> the kernel uses.

LLVM has done that before (eg adding -fno-strict-overflow). I don't
think that option covers this case however.

Anton

Re: llist code relies on undefined behaviour, upsets llvm/clang

2017-01-16 Thread Anton Blanchard

Hi Peter,

> Last I checked I couldn't build a x86_64 kernel with llvm. So no, not
> something I've ever ran into.
> 
> Also, I would argue that this is broken in llvm, the kernel very much
> relies on things like this all over the place. Sure, we're way outside
> of what the C language spec says, but who bloody cares ;-)

True, but is there anything preventing gcc from implementing this
optimisation in the future? If we are relying on undefined behaviour we
should have a -fno-strict-* option to cover it.

> If llvm wants to compile the kernel, it needs to learn the C dialect
> the kernel uses.

LLVM has done that before (eg adding -fno-strict-overflow). I don't
think that option covers this case however.

Anton

llist code relies on undefined behaviour, upsets llvm/clang

2017-01-15 Thread Anton Blanchard

Hi,

I was debugging a hang on a ppc64le kernel built with clang, and it
looks to be undefined behaviour with pointer wrapping in the llist code.

A test case is below. llist_for_each_entry() does container_of() on a
NULL pointer, which wraps our pointer negative, then adds the same
offset back in and expects to get back to NULL. Unfortunately clang
decides that this can never be NULL and optimises it into an infinite
loop.

Build with -DFIX, such that the llist_node has a zero offset from the
start of the struct, and things work.

Is anyone other than ppc64le building kernels with llvm/clang these
days? This should reproduce on ARM64 and x86-64.

Anton
--

#include 

#define __compiler_offsetof(a, b)   \
__builtin_offsetof(a, b)

#undef offsetof
#ifdef __compiler_offsetof
#define offsetof(TYPE, MEMBER)  __compiler_offsetof(TYPE, MEMBER)
#else
#define offsetof(TYPE, MEMBER)  ((size_t)&((TYPE *)0)->MEMBER)
#endif

struct llist_node {
struct llist_node *next;
};

#define container_of(ptr, type, member) ({  \
const typeof( ((type *)0)->member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type,member) );})

#define llist_entry(ptr, type, member)  \
container_of(ptr, type, member)

#define llist_for_each_entry(pos, node, member) \
for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
 &(pos)->member != NULL;\
 (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))

struct foo {
#ifndef FIX
unsigned long a;
#endif
struct llist_node ll;
};

void working(void);

struct llist_node *ptr;

void bar(void)
{
struct foo *f;

llist_for_each_entry(f, ptr, ll) {
}

working();
}

llist code relies on undefined behaviour, upsets llvm/clang

2017-01-15 Thread Anton Blanchard

Hi,

I was debugging a hang on a ppc64le kernel built with clang, and it
looks to be undefined behaviour with pointer wrapping in the llist code.

A test case is below. llist_for_each_entry() does container_of() on a
NULL pointer, which wraps our pointer negative, then adds the same
offset back in and expects to get back to NULL. Unfortunately clang
decides that this can never be NULL and optimises it into an infinite
loop.

Build with -DFIX, such that the llist_node has a zero offset from the
start of the struct, and things work.

Is anyone other than ppc64le building kernels with llvm/clang these
days? This should reproduce on ARM64 and x86-64.

Anton
--

#include 

#define __compiler_offsetof(a, b)   \
__builtin_offsetof(a, b)

#undef offsetof
#ifdef __compiler_offsetof
#define offsetof(TYPE, MEMBER)  __compiler_offsetof(TYPE, MEMBER)
#else
#define offsetof(TYPE, MEMBER)  ((size_t)&((TYPE *)0)->MEMBER)
#endif

struct llist_node {
struct llist_node *next;
};

#define container_of(ptr, type, member) ({  \
const typeof( ((type *)0)->member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type,member) );})

#define llist_entry(ptr, type, member)  \
container_of(ptr, type, member)

#define llist_for_each_entry(pos, node, member) \
for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
 &(pos)->member != NULL;\
 (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))

struct foo {
#ifndef FIX
unsigned long a;
#endif
struct llist_node ll;
};

void working(void);

struct llist_node *ptr;

void bar(void)
{
struct foo *f;

llist_for_each_entry(f, ptr, ll) {
}

working();
}

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

2017-01-05 Thread Anton Blanchard

Hi Ted,

> Anton or Chandan, could you do me a favor and verify whether or not
> 64k block sizes are working for you on ppcle on ext4 by running
> xfstests?  Light duty testing works for me but when I stress ext4 with
> pagesize==blocksize on ppcle64 via xfstests, it blows up.  I suspect
> (but am not sure) it's due to (non-upstream) device driver issues, and
> a verification that you can run xfstests on your ppcle64 systems using
> standard upstream device drivers would be very helpful, since I don't
> have easy console access on the machines I have access to at
> $WORK.  :-(

I fired off an xfstests run, and it looks good. There are 3 failures,
but they seem to be setup issues on my part. I also double checked
those same three failed on 4.8.

Chandan has been running the test suite regularly, and plans to do a
run against mainline too.

Anton

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

2017-01-05 Thread Anton Blanchard

Hi Ted,

> Anton or Chandan, could you do me a favor and verify whether or not
> 64k block sizes are working for you on ppcle on ext4 by running
> xfstests?  Light duty testing works for me but when I stress ext4 with
> pagesize==blocksize on ppcle64 via xfstests, it blows up.  I suspect
> (but am not sure) it's due to (non-upstream) device driver issues, and
> a verification that you can run xfstests on your ppcle64 systems using
> standard upstream device drivers would be very helpful, since I don't
> have easy console access on the machines I have access to at
> $WORK.  :-(

I fired off an xfstests run, and it looks good. There are 3 failures,
but they seem to be setup issues on my part. I also double checked
those same three failed on 4.8.

Chandan has been running the test suite regularly, and plans to do a
run against mainline too.

Anton

ext4 filesystem corruption with 4.10-rc2 on ppc64le

2017-01-03 Thread Anton Blanchard

Hi,

I'm consistently seeing ext4 filesystem corruption using a mainline
kernel. It doesn't take much to trigger it - download a ppc64le Ubuntu
cloud image, boot it in KVM and run:

sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot

And it never makes it back up, dying with rather severe filesystem
corruption.

I've narrowed it down to:

64e1c57fa474 ("ext4: Use clean_bdev_aliases() instead of iteration")
e64855c6cfaa ("fs: Add helper to clean bdev aliases under a bh and use it")
ce98321bf7d2 ("fs: Remove unmap_underlying_metadata")

Backing these patches out fixes the issue.

Anton

ext4 filesystem corruption with 4.10-rc2 on ppc64le

2017-01-03 Thread Anton Blanchard

Hi,

I'm consistently seeing ext4 filesystem corruption using a mainline
kernel. It doesn't take much to trigger it - download a ppc64le Ubuntu
cloud image, boot it in KVM and run:

sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot

And it never makes it back up, dying with rather severe filesystem
corruption.

I've narrowed it down to:

64e1c57fa474 ("ext4: Use clean_bdev_aliases() instead of iteration")
e64855c6cfaa ("fs: Add helper to clean bdev aliases under a bh and use it")
ce98321bf7d2 ("fs: Remove unmap_underlying_metadata")

Backing these patches out fixes the issue.

Anton

Re: [PATCH] perf TUI: Don't throw error for zero length symbols

2016-12-16 Thread Anton Blanchard

Hi Ravi,

> > perf report (with TUI) exits with error when it finds a sample of
> > zero length symbol(i.e. addr == sym->start == sym->end). Actually
> > these are valid samples. Don't exit TUI and show report with such
> > symbols.
> >
> > Link: https://lkml.org/lkml/2016/10/8/189

You can add:

Tested-by: Anton Blanchard <an...@samba.org>

Also, since this issue makes perf report pretty much useless on
ppc64, can we mark it for stable@, at least to get it into 4.9 where
the ppc64 kernel changes that triggered this appeared?

Anton

> > Reported-by: Anton Blanchard <an...@samba.org>
> > Signed-off-by: Ravi Bangoria <ravi.bango...@linux.vnet.ibm.com>
> > ---
> >  tools/perf/util/annotate.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> > index aeb5a44..430d039 100644
> > --- a/tools/perf/util/annotate.c
> > +++ b/tools/perf/util/annotate.c
> > @@ -593,7 +593,8 @@ static int __symbol__inc_addr_samples(struct
> > symbol *sym, struct map *map,
> >
> > pr_debug3("%s: addr=%#" PRIx64 "\n", __func__,
> > map->unmap_ip(map, addr));
> >
> > -   if (addr < sym->start || addr >= sym->end) {
> > +   if ((addr < sym->start || addr >= sym->end) &&
> > +   (addr != sym->end || sym->start != sym->end)) {
> > pr_debug("%s(%d): ERANGE! sym->name=%s, start=%#"
> > PRIx64 ", addr=%#" PRIx64 ", end=%#" PRIx64 "\n", __func__,
> > __LINE__, sym->name, sym->start, addr, sym->end); return -ERANGE;  
>

Re: [PATCH] perf TUI: Don't throw error for zero length symbols

2016-12-16 Thread Anton Blanchard

Hi Ravi,

> > perf report (with TUI) exits with error when it finds a sample of
> > zero length symbol(i.e. addr == sym->start == sym->end). Actually
> > these are valid samples. Don't exit TUI and show report with such
> > symbols.
> >
> > Link: https://lkml.org/lkml/2016/10/8/189

You can add:

Tested-by: Anton Blanchard 

Also, since this issue makes perf report pretty much useless on
ppc64, can we mark it for stable@, at least to get it into 4.9 where
the ppc64 kernel changes that triggered this appeared?

Anton

> > Reported-by: Anton Blanchard 
> > Signed-off-by: Ravi Bangoria 
> > ---
> >  tools/perf/util/annotate.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> > index aeb5a44..430d039 100644
> > --- a/tools/perf/util/annotate.c
> > +++ b/tools/perf/util/annotate.c
> > @@ -593,7 +593,8 @@ static int __symbol__inc_addr_samples(struct
> > symbol *sym, struct map *map,
> >
> > pr_debug3("%s: addr=%#" PRIx64 "\n", __func__,
> > map->unmap_ip(map, addr));
> >
> > -   if (addr < sym->start || addr >= sym->end) {
> > +   if ((addr < sym->start || addr >= sym->end) &&
> > +   (addr != sym->end || sym->start != sym->end)) {
> > pr_debug("%s(%d): ERANGE! sym->name=%s, start=%#"
> > PRIx64 ", addr=%#" PRIx64 ", end=%#" PRIx64 "\n", __func__,
> > __LINE__, sym->name, sym->start, addr, sym->end); return -ERANGE;  
>

Re: perf TUI fails with "failed to process type: 64"

2016-11-20 Thread Anton Blanchard

Hi,

I forgot about the set of issues below. Michael had a suggested powerpc
fix for 3, but it it would be nice to fix the perf bugs in 1 and 2.

Anton
--

> Updating to mainline as of last night, I started seeing the following
> error when running the perf report TUI:
> 
> 0x46068 [0x8]: failed to process type: 68
> 
> This event is just PERF_RECORD_FINISHED_ROUND:
> 
> 0x46068 [0x8]: event: 68
> .
> . ... raw event: size 8 bytes
> .  :  44 00 00 00 00 00 08 00
> D...
> 
> 0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND
> 
> Which of course is not our error. It took me a while to find the real
> culprit:
> 
>  14c00-14c00 g exc_virt_0x4c00_system_call
> 
> A zero length symbol, which __symbol__inc_addr_samples() barfs on:
> 
> if (addr < sym->start || addr >= sym->end) {
> ...
>   return -ERANGE;
> 
> Seems like we have 3 bugs here:
> 
> 1. Output the real source of the error instead of
> PERF_RECORD_FINISHED_ROUND
> 
> 2. Don't exit the TUI if we find a sample on a zero length symbol
> 
> 3. Why do we have zero length symbols in the first place? Does the
> recent ppc64 exception clean up have something to do with it?
> 
> Anton

Re: perf TUI fails with "failed to process type: 64"

2016-11-20 Thread Anton Blanchard

Hi,

I forgot about the set of issues below. Michael had a suggested powerpc
fix for 3, but it it would be nice to fix the perf bugs in 1 and 2.

Anton
--

> Updating to mainline as of last night, I started seeing the following
> error when running the perf report TUI:
> 
> 0x46068 [0x8]: failed to process type: 68
> 
> This event is just PERF_RECORD_FINISHED_ROUND:
> 
> 0x46068 [0x8]: event: 68
> .
> . ... raw event: size 8 bytes
> .  :  44 00 00 00 00 00 08 00
> D...
> 
> 0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND
> 
> Which of course is not our error. It took me a while to find the real
> culprit:
> 
>  14c00-14c00 g exc_virt_0x4c00_system_call
> 
> A zero length symbol, which __symbol__inc_addr_samples() barfs on:
> 
> if (addr < sym->start || addr >= sym->end) {
> ...
>   return -ERANGE;
> 
> Seems like we have 3 bugs here:
> 
> 1. Output the real source of the error instead of
> PERF_RECORD_FINISHED_ROUND
> 
> 2. Don't exit the TUI if we find a sample on a zero length symbol
> 
> 3. Why do we have zero length symbols in the first place? Does the
> recent ppc64 exception clean up have something to do with it?
> 
> Anton

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

2016-11-05 Thread Anton Blanchard

Hi,

> kprobe, uprobe, hw-breakpoint and xmon are the only user of
> emulate_step.
> 
> Kprobe / uprobe single-steps instruction if they can't emulate it, so
> there is no problem with them. As I mention, hw-breakpoint is broken.
> However I'm not sure about xmon, I need to check that.

I was mostly concerned that it would impact kprobes. Sounds like we are
ok there.

> So yes, there is no user-visible feature that depends on this.

Aren't hardware breakpoints exposed via perf? I'd call perf
user-visible.

Anton

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

2016-11-05 Thread Anton Blanchard

Hi,

> kprobe, uprobe, hw-breakpoint and xmon are the only user of
> emulate_step.
> 
> Kprobe / uprobe single-steps instruction if they can't emulate it, so
> there is no problem with them. As I mention, hw-breakpoint is broken.
> However I'm not sure about xmon, I need to check that.

I was mostly concerned that it would impact kprobes. Sounds like we are
ok there.

> So yes, there is no user-visible feature that depends on this.

Aren't hardware breakpoints exposed via perf? I'd call perf
user-visible.

Anton

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

2016-11-02 Thread Anton Blanchard

Hi Ravi,

> emulate_step() uses a number of underlying kernel functions that were
> initially not enabled for LE. This has been rectified since. So, fix
> emulate_step() for LE for the corresponding instructions.

Thanks. Should this be queued up for stable?

Anton

> Reported-by: Anton Blanchard <an...@samba.org>
> Signed-off-by: Ravi Bangoria <ravi.bango...@linux.vnet.ibm.com>
> ---
>  arch/powerpc/lib/sstep.c | 20 
>  1 file changed, 20 deletions(-)
> 
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index 3362299..6ca3b90 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -1807,8 +1807,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto instr_done;
>  
>   case LARX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (op.ea & (size - 1))
>   break;  /* can't handle
> misaligned */ err = -EFAULT;
> @@ -1832,8 +1830,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto ldst_done;
>  
>   case STCX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (op.ea & (size - 1))
>   break;  /* can't handle
> misaligned */ err = -EFAULT;
> @@ -1859,8 +1855,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto ldst_done;
>  
>   case LOAD:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = read_mem(>gpr[op.reg], op.ea, size,
> regs); if (!err) {
>   if (op.type & SIGNEXT)
> @@ -1872,8 +1866,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) 
>  #ifdef CONFIG_PPC_FPU
>   case LOAD_FP:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (size == 4)
>   err = do_fp_load(op.reg, do_lfs, op.ea,
> size, regs); else
> @@ -1882,15 +1874,11 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) #endif
>  #ifdef CONFIG_ALTIVEC
>   case LOAD_VMX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vec_load(op.reg, do_lvx, op.ea & ~0xfUL,
> regs); goto ldst_done;
>  #endif
>  #ifdef CONFIG_VSX
>   case LOAD_VSX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vsx_load(op.reg, do_lxvd2x, op.ea, regs);
>   goto ldst_done;
>  #endif
> @@ -1913,8 +1901,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto instr_done;
>  
>   case STORE:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if ((op.type & UPDATE) && size == sizeof(long) &&
>   op.reg == 1 && op.update_reg == 1 &&
>   !(regs->msr & MSR_PR) &&
> @@ -1927,8 +1913,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) 
>  #ifdef CONFIG_PPC_FPU
>   case STORE_FP:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (size == 4)
>   err = do_fp_store(op.reg, do_stfs, op.ea,
> size, regs); else
> @@ -1937,15 +1921,11 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) #endif
>  #ifdef CONFIG_ALTIVEC
>   case STORE_VMX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vec_store(op.reg, do_stvx, op.ea & ~0xfUL,
> regs); goto ldst_done;
>  #endif
>  #ifdef CONFIG_VSX
>   case STORE_VSX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vsx_store(op.reg, do_stxvd2x, op.ea, regs);
>   goto ldst_done;
>  #endif

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

2016-11-02 Thread Anton Blanchard

Hi Ravi,

> emulate_step() uses a number of underlying kernel functions that were
> initially not enabled for LE. This has been rectified since. So, fix
> emulate_step() for LE for the corresponding instructions.

Thanks. Should this be queued up for stable?

Anton

> Reported-by: Anton Blanchard 
> Signed-off-by: Ravi Bangoria 
> ---
>  arch/powerpc/lib/sstep.c | 20 
>  1 file changed, 20 deletions(-)
> 
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index 3362299..6ca3b90 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -1807,8 +1807,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto instr_done;
>  
>   case LARX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (op.ea & (size - 1))
>   break;  /* can't handle
> misaligned */ err = -EFAULT;
> @@ -1832,8 +1830,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto ldst_done;
>  
>   case STCX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (op.ea & (size - 1))
>   break;  /* can't handle
> misaligned */ err = -EFAULT;
> @@ -1859,8 +1855,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto ldst_done;
>  
>   case LOAD:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = read_mem(>gpr[op.reg], op.ea, size,
> regs); if (!err) {
>   if (op.type & SIGNEXT)
> @@ -1872,8 +1866,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) 
>  #ifdef CONFIG_PPC_FPU
>   case LOAD_FP:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (size == 4)
>   err = do_fp_load(op.reg, do_lfs, op.ea,
> size, regs); else
> @@ -1882,15 +1874,11 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) #endif
>  #ifdef CONFIG_ALTIVEC
>   case LOAD_VMX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vec_load(op.reg, do_lvx, op.ea & ~0xfUL,
> regs); goto ldst_done;
>  #endif
>  #ifdef CONFIG_VSX
>   case LOAD_VSX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vsx_load(op.reg, do_lxvd2x, op.ea, regs);
>   goto ldst_done;
>  #endif
> @@ -1913,8 +1901,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) goto instr_done;
>  
>   case STORE:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if ((op.type & UPDATE) && size == sizeof(long) &&
>   op.reg == 1 && op.update_reg == 1 &&
>   !(regs->msr & MSR_PR) &&
> @@ -1927,8 +1913,6 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) 
>  #ifdef CONFIG_PPC_FPU
>   case STORE_FP:
> - if (regs->msr & MSR_LE)
> - return 0;
>   if (size == 4)
>   err = do_fp_store(op.reg, do_stfs, op.ea,
> size, regs); else
> @@ -1937,15 +1921,11 @@ int __kprobes emulate_step(struct pt_regs
> *regs, unsigned int instr) #endif
>  #ifdef CONFIG_ALTIVEC
>   case STORE_VMX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vec_store(op.reg, do_stvx, op.ea & ~0xfUL,
> regs); goto ldst_done;
>  #endif
>  #ifdef CONFIG_VSX
>   case STORE_VSX:
> - if (regs->msr & MSR_LE)
> - return 0;
>   err = do_vsx_store(op.reg, do_stxvd2x, op.ea, regs);
>   goto ldst_done;
>  #endif

[tip:perf/urgent] perf jit: Fix build issue on Ubuntu

2016-10-17 Thread tip-bot for Anton Blanchard

Commit-ID:  53613e005496234bb684e5db551fbcededa73999
Gitweb: http://git.kernel.org/tip/53613e005496234bb684e5db551fbcededa73999
Author: Anton Blanchard <an...@samba.org>
AuthorDate: Thu, 13 Oct 2016 13:20:43 +1100
Committer:  Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Mon, 17 Oct 2016 11:25:34 -0300

perf jit: Fix build issue on Ubuntu

When building on Ubuntu 16.04, I get the following error:

Makefile:49: *** the openjdk development package appears to me missing, install 
and try again.  Stop.

The problem is that update-java-alternatives has multiple spaces between
fields, and cut treats each space as a new delimiter:

java-1.8.0-openjdk-ppc64el 1081   
/usr/lib/jvm/java-1.8.0-openjdk-ppc64el

Fix this by using awk, which handles this fine.

Signed-off-by: Anton Blanchard <an...@samba.org>
Reviewed-by: Stephane Eranian <eran...@google.com>
Cc: Alexander Shishkin <alexander.shish...@linux.intel.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Link: 
http://lkml.kernel.org/r/1476325243-15788-1-git-send-email-an...@ozlabs.org
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
 tools/perf/jvmti/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/jvmti/Makefile b/tools/perf/jvmti/Makefile
index 5ce61a1..df14e6b 100644
--- a/tools/perf/jvmti/Makefile
+++ b/tools/perf/jvmti/Makefile
@@ -36,7 +36,7 @@ SOLIBEXT=so
 # The following works at least on fedora 23, you may need the next
 # line for other distros.
 ifneq (,$(wildcard /usr/sbin/update-java-alternatives))
-JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | cut -d ' ' -f 3)
+JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | awk '{print 
$$3}')
 else
   ifneq (,$(wildcard /usr/sbin/alternatives))
 JDIR=$(shell alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 
's%/jre/bin/java.%%g')

[tip:perf/urgent] perf jit: Fix build issue on Ubuntu

2016-10-17 Thread tip-bot for Anton Blanchard

Commit-ID:  53613e005496234bb684e5db551fbcededa73999
Gitweb: http://git.kernel.org/tip/53613e005496234bb684e5db551fbcededa73999
Author: Anton Blanchard 
AuthorDate: Thu, 13 Oct 2016 13:20:43 +1100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 17 Oct 2016 11:25:34 -0300

perf jit: Fix build issue on Ubuntu

When building on Ubuntu 16.04, I get the following error:

Makefile:49: *** the openjdk development package appears to me missing, install 
and try again.  Stop.

The problem is that update-java-alternatives has multiple spaces between
fields, and cut treats each space as a new delimiter:

java-1.8.0-openjdk-ppc64el 1081   
/usr/lib/jvm/java-1.8.0-openjdk-ppc64el

Fix this by using awk, which handles this fine.

Signed-off-by: Anton Blanchard 
Reviewed-by: Stephane Eranian 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1476325243-15788-1-git-send-email-an...@ozlabs.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/jvmti/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/jvmti/Makefile b/tools/perf/jvmti/Makefile
index 5ce61a1..df14e6b 100644
--- a/tools/perf/jvmti/Makefile
+++ b/tools/perf/jvmti/Makefile
@@ -36,7 +36,7 @@ SOLIBEXT=so
 # The following works at least on fedora 23, you may need the next
 # line for other distros.
 ifneq (,$(wildcard /usr/sbin/update-java-alternatives))
-JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | cut -d ' ' -f 3)
+JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | awk '{print 
$$3}')
 else
   ifneq (,$(wildcard /usr/sbin/alternatives))
 JDIR=$(shell alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 
's%/jre/bin/java.%%g')

[PATCH] perf jit: Fix build issue on Ubuntu

2016-10-12 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

When building on Ubuntu 16.04, I get the following error:

Makefile:49: *** the openjdk development package appears to me missing, install 
and try again.  Stop.

The problem is that update-java-alternatives has multiple spaces between
fields, and cut treats each space as a new delimiter:

java-1.8.0-openjdk-ppc64el 1081   
/usr/lib/jvm/java-1.8.0-openjdk-ppc64el

Fix this by using awk, which handles this fine.

Signed-off-by: Anton Blanchard <an...@samba.org>
---
 tools/perf/jvmti/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/jvmti/Makefile b/tools/perf/jvmti/Makefile
index 5ce61a1..df14e6b 100644
--- a/tools/perf/jvmti/Makefile
+++ b/tools/perf/jvmti/Makefile
@@ -36,7 +36,7 @@ SOLIBEXT=so
 # The following works at least on fedora 23, you may need the next
 # line for other distros.
 ifneq (,$(wildcard /usr/sbin/update-java-alternatives))
-JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | cut -d ' ' -f 3)
+JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | awk '{print 
$$3}')
 else
   ifneq (,$(wildcard /usr/sbin/alternatives))
 JDIR=$(shell alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 
's%/jre/bin/java.%%g')
-- 
2.7.4

[PATCH] perf jit: Fix build issue on Ubuntu

2016-10-12 Thread Anton Blanchard

From: Anton Blanchard 

When building on Ubuntu 16.04, I get the following error:

Makefile:49: *** the openjdk development package appears to me missing, install 
and try again.  Stop.

The problem is that update-java-alternatives has multiple spaces between
fields, and cut treats each space as a new delimiter:

java-1.8.0-openjdk-ppc64el 1081   
/usr/lib/jvm/java-1.8.0-openjdk-ppc64el

Fix this by using awk, which handles this fine.

Signed-off-by: Anton Blanchard 
---
 tools/perf/jvmti/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/jvmti/Makefile b/tools/perf/jvmti/Makefile
index 5ce61a1..df14e6b 100644
--- a/tools/perf/jvmti/Makefile
+++ b/tools/perf/jvmti/Makefile
@@ -36,7 +36,7 @@ SOLIBEXT=so
 # The following works at least on fedora 23, you may need the next
 # line for other distros.
 ifneq (,$(wildcard /usr/sbin/update-java-alternatives))
-JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | cut -d ' ' -f 3)
+JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | awk '{print 
$$3}')
 else
   ifneq (,$(wildcard /usr/sbin/alternatives))
 JDIR=$(shell alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 
's%/jre/bin/java.%%g')
-- 
2.7.4

Re: perf TUI fails with "failed to process type: 64"

2016-10-10 Thread Anton Blanchard

Hi Michael,

> >  14c00-14c00 g exc_virt_0x4c00_system_call  
>^
>What's this? The address? If so it's wrong?

Offset into the binary I think, there's one 64kB page of ELF gunk at
the start.

> Seems likely. But I can't see why.
> 
> AFAICS we have never emitted a size for those symbols:
> 
> Old:
> $ nm --print-size build/vmlinux | grep -w system_call_relon_pSeries
> c0004c00 T system_call_relon_pSeries
> 
> New:
> $ nm --print-size build/vmlinux | grep -w exc_virt_0x4c00_system_call
> c0004c00 T exc_virt_0x4c00_system_call
> 
> 
> It also doesn't look like we're emitting another symbol with the same
> address, which has caused confusion in the past:
> 
> Old:
> c0004c00 T exc_virt_0x4c00_system_call
> c0004d00 T exc_virt_0x4d00_single_step
> 
> New:
> c0004c00 T system_call_relon_pSeries
> c0004d00 T single_step_relon_pSeries
> 
> So more digging required.

Thanks for checking, it's starting to sound like a perf bug.

Anton

Re: perf TUI fails with "failed to process type: 64"

2016-10-10 Thread Anton Blanchard

Hi Michael,

> >  14c00-14c00 g exc_virt_0x4c00_system_call  
>^
>What's this? The address? If so it's wrong?

Offset into the binary I think, there's one 64kB page of ELF gunk at
the start.

> Seems likely. But I can't see why.
> 
> AFAICS we have never emitted a size for those symbols:
> 
> Old:
> $ nm --print-size build/vmlinux | grep -w system_call_relon_pSeries
> c0004c00 T system_call_relon_pSeries
> 
> New:
> $ nm --print-size build/vmlinux | grep -w exc_virt_0x4c00_system_call
> c0004c00 T exc_virt_0x4c00_system_call
> 
> 
> It also doesn't look like we're emitting another symbol with the same
> address, which has caused confusion in the past:
> 
> Old:
> c0004c00 T exc_virt_0x4c00_system_call
> c0004d00 T exc_virt_0x4d00_single_step
> 
> New:
> c0004c00 T system_call_relon_pSeries
> c0004d00 T single_step_relon_pSeries
> 
> So more digging required.

Thanks for checking, it's starting to sound like a perf bug.

Anton

perf TUI fails with "failed to process type: 64"

2016-10-08 Thread Anton Blanchard

Hi,

Updating to mainline as of last night, I started seeing the following
error when running the perf report TUI:

0x46068 [0x8]: failed to process type: 68

This event is just PERF_RECORD_FINISHED_ROUND:

0x46068 [0x8]: event: 68
.
. ... raw event: size 8 bytes
.  :  44 00 00 00 00 00 08 00  D...

0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND

Which of course is not our error. It took me a while to find the real
culprit:

 14c00-14c00 g exc_virt_0x4c00_system_call

A zero length symbol, which __symbol__inc_addr_samples() barfs on:

if (addr < sym->start || addr >= sym->end) {
...
return -ERANGE;

Seems like we have 3 bugs here:

1. Output the real source of the error instead of PERF_RECORD_FINISHED_ROUND

2. Don't exit the TUI if we find a sample on a zero length symbol

3. Why do we have zero length symbols in the first place? Does the recent
   ppc64 exception clean up have something to do with it?

Anton

perf TUI fails with "failed to process type: 64"

2016-10-08 Thread Anton Blanchard

Hi,

Updating to mainline as of last night, I started seeing the following
error when running the perf report TUI:

0x46068 [0x8]: failed to process type: 68

This event is just PERF_RECORD_FINISHED_ROUND:

0x46068 [0x8]: event: 68
.
. ... raw event: size 8 bytes
.  :  44 00 00 00 00 00 08 00  D...

0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND

Which of course is not our error. It took me a while to find the real
culprit:

 14c00-14c00 g exc_virt_0x4c00_system_call

A zero length symbol, which __symbol__inc_addr_samples() barfs on:

if (addr < sym->start || addr >= sym->end) {
...
return -ERANGE;

Seems like we have 3 bugs here:

1. Output the real source of the error instead of PERF_RECORD_FINISHED_ROUND

2. Don't exit the TUI if we find a sample on a zero length symbol

3. Why do we have zero length symbols in the first place? Does the recent
   ppc64 exception clean up have something to do with it?

Anton

Re: [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption

2016-09-28 Thread Anton Blanchard

Hi Marcelo

> This series fixes the memory corruption found by Jan Stancek in
> 4.8-rc7. The problem however also affects previous versions of the
> driver.

If it affects previous versions, please add the lines in the sign off to
get it into the stable kernels.

Anton

Re: [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption

2016-09-28 Thread Anton Blanchard

Hi Marcelo

> This series fixes the memory corruption found by Jan Stancek in
> 4.8-rc7. The problem however also affects previous versions of the
> driver.

If it affects previous versions, please add the lines in the sign off to
get it into the stable kernels.

Anton

Re: [PATCH] Work around for enabling CONFIG_CMDLINE on ppc64le

2016-09-22 Thread Anton Blanchard

Hi,

> But I can't merge that patch.
> 
> Our options are one or both of:
>  - get GCC fixed and backport the fix to the compilers we care about.
>  - blacklist the broken compiler versions.
> 
> Is there a GCC bug filed for this?

Likely: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709

We need confirmation this patch fixes the 6.x issue too and that we need
a backport.

Anton

Re: [PATCH] Work around for enabling CONFIG_CMDLINE on ppc64le

2016-09-22 Thread Anton Blanchard

Hi,

> But I can't merge that patch.
> 
> Our options are one or both of:
>  - get GCC fixed and backport the fix to the compilers we care about.
>  - blacklist the broken compiler versions.
> 
> Is there a GCC bug filed for this?

Likely: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709

We need confirmation this patch fixes the 6.x issue too and that we need
a backport.

Anton

[tip:perf/urgent] perf symbols: Fix annotation of objects with debuginfo files

2016-08-16 Thread tip-bot for Anton Blanchard

Commit-ID:  50de1a0c54cdbc69a6dbcbc323f53daf95a4050e
Gitweb: http://git.kernel.org/tip/50de1a0c54cdbc69a6dbcbc323f53daf95a4050e
Author: Anton Blanchard <an...@samba.org>
AuthorDate: Sat, 13 Aug 2016 11:55:33 +1000
Committer:  Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Mon, 15 Aug 2016 16:49:57 -0300

perf symbols: Fix annotation of objects with debuginfo files

Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso
to calculate objdump address") started storing the offset of
the text section for all DSOs:

   if (elf_section_by_name(elf, , , ".text", NULL))
   dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;

Unfortunately this breaks debuginfo files, because we need to calculate
the offset of the text section in the associated executable file. As a
result perf annotate returns junk for all debuginfo files.

Fix this by using runtime_ss->elf which should point at the executable
when parsing a debuginfo file.

Signed-off-by: Anton Blanchard <an...@samba.org>
Reviewed-by: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>
Tested-by: Wang Nan <wangn...@huawei.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ravi Bangoria <ravi.bango...@linux.vnet.ibm.com>
Cc: sta...@vger.kernel.org # v4.6+
Fixes: 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate 
objdump address")
Link: http://lkml.kernel.org/r/20160813115533.6de17912@kryten
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
 tools/perf/util/symbol-elf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a34321e..a811c13 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -837,7 +837,8 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss->symtab;
shdr = syms_ss->symshdr;
 
-   if (elf_section_by_name(elf, , , ".text", NULL))
+   if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
+   ".text", NULL))
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
 
if (runtime_ss->opdsec)

[tip:perf/urgent] perf symbols: Fix annotation of objects with debuginfo files

2016-08-16 Thread tip-bot for Anton Blanchard

Commit-ID:  50de1a0c54cdbc69a6dbcbc323f53daf95a4050e
Gitweb: http://git.kernel.org/tip/50de1a0c54cdbc69a6dbcbc323f53daf95a4050e
Author: Anton Blanchard 
AuthorDate: Sat, 13 Aug 2016 11:55:33 +1000
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 15 Aug 2016 16:49:57 -0300

perf symbols: Fix annotation of objects with debuginfo files

Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso
to calculate objdump address") started storing the offset of
the text section for all DSOs:

   if (elf_section_by_name(elf, , , ".text", NULL))
   dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;

Unfortunately this breaks debuginfo files, because we need to calculate
the offset of the text section in the associated executable file. As a
result perf annotate returns junk for all debuginfo files.

Fix this by using runtime_ss->elf which should point at the executable
when parsing a debuginfo file.

Signed-off-by: Anton Blanchard 
Reviewed-by: Naveen N. Rao 
Tested-by: Wang Nan 
Cc: Peter Zijlstra 
Cc: Ravi Bangoria 
Cc: sta...@vger.kernel.org # v4.6+
Fixes: 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate 
objdump address")
Link: http://lkml.kernel.org/r/20160813115533.6de17912@kryten
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol-elf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a34321e..a811c13 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -837,7 +837,8 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss->symtab;
shdr = syms_ss->symshdr;
 
-   if (elf_section_by_name(elf, , , ".text", NULL))
+   if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
+   ".text", NULL))
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
 
if (runtime_ss->opdsec)

[PATCH v2] perf symbols: Fix annotation of objects with debuginfo files

2016-08-12 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso
to calculate objdump address") started storing the offset of
the text section for all DSOs: 

   if (elf_section_by_name(elf, , , ".text", NULL))
   dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;

Unfortunately this breaks debuginfo files, because we need to calculate
the offset of the text section in the associated executable file. As a
result perf annotate returns junk for all debuginfo files.

Fix this by using runtime_ss->elf which should point at the executable
when parsing a debuginfo file.

Cc: sta...@vger.kernel.org # v4.6+
Fixes: 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate 
objdump address")
Signed-off-by: Anton Blanchard <an...@samba.org>
---

v2: Fix from Naveen

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a34321e..a811c13 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -837,7 +837,8 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss->symtab;
shdr = syms_ss->symshdr;
 
-   if (elf_section_by_name(elf, , , ".text", NULL))
+   if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
+   ".text", NULL))
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
 
if (runtime_ss->opdsec)

[PATCH v2] perf symbols: Fix annotation of objects with debuginfo files

2016-08-12 Thread Anton Blanchard

From: Anton Blanchard 

Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso
to calculate objdump address") started storing the offset of
the text section for all DSOs: 

   if (elf_section_by_name(elf, , , ".text", NULL))
   dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;

Unfortunately this breaks debuginfo files, because we need to calculate
the offset of the text section in the associated executable file. As a
result perf annotate returns junk for all debuginfo files.

Fix this by using runtime_ss->elf which should point at the executable
when parsing a debuginfo file.

Cc: sta...@vger.kernel.org # v4.6+
Fixes: 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate 
objdump address")
Signed-off-by: Anton Blanchard 
---

v2: Fix from Naveen

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a34321e..a811c13 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -837,7 +837,8 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss->symtab;
shdr = syms_ss->symshdr;
 
-   if (elf_section_by_name(elf, , , ".text", NULL))
+   if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
+   ".text", NULL))
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
 
if (runtime_ss->opdsec)

[PATCH] perf symbols: Fix annotation of objects with debuginfo files

2016-08-12 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso
to calculate objdump address") started storing the offset of
the text section for all DSOs: 

   if (elf_section_by_name(elf, , , ".text", NULL))
   dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;

Unfortunately this breaks debuginfo files, because we need to calculate
the offset of the text section in the associated executable file. As a
result perf annotate returns junk for all debuginfo files.

Fix this by using runtime_ss->elf which should point at the executable
when parsing a debuginfo file.

Cc: sta...@vger.kernel.org # v4.6+
Fixes: 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate 
objdump address")
Signed-off-by: Anton Blanchard <an...@samba.org>
---

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a34321e..9e36073 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -837,7 +837,7 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss->symtab;
shdr = syms_ss->symshdr;
 
-   if (elf_section_by_name(elf, , , ".text", NULL))
+   if (elf_section_by_name(runtime_ss->elf, , , ".text", NULL))
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
 
if (runtime_ss->opdsec)

[PATCH] perf symbols: Fix annotation of objects with debuginfo files

2016-08-12 Thread Anton Blanchard

From: Anton Blanchard 

Commit 73cdf0c6ea9c ("perf symbols: Record text offset in dso
to calculate objdump address") started storing the offset of
the text section for all DSOs: 

   if (elf_section_by_name(elf, , , ".text", NULL))
   dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;

Unfortunately this breaks debuginfo files, because we need to calculate
the offset of the text section in the associated executable file. As a
result perf annotate returns junk for all debuginfo files.

Fix this by using runtime_ss->elf which should point at the executable
when parsing a debuginfo file.

Cc: sta...@vger.kernel.org # v4.6+
Fixes: 73cdf0c6ea9c ("perf symbols: Record text offset in dso to calculate 
objdump address")
Signed-off-by: Anton Blanchard 
---

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a34321e..9e36073 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -837,7 +837,7 @@ int dso__load_sym(struct dso *dso, struct map *map,
sec = syms_ss->symtab;
shdr = syms_ss->symshdr;
 
-   if (elf_section_by_name(elf, , , ".text", NULL))
+   if (elf_section_by_name(runtime_ss->elf, , , ".text", NULL))
dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
 
if (runtime_ss->opdsec)

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

2016-08-12 Thread Anton Blanchard

Hi Arnaldo,

> Anyway, Anton, does this fix the problem for you?

Yes it does, thanks!

Anton

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

2016-08-12 Thread Anton Blanchard

Hi Arnaldo,

> Anyway, Anton, does this fix the problem for you?

Yes it does, thanks!

Anton

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

2016-08-10 Thread Anton Blanchard

Hi,

> Powerpc has Global Entry Point and Local Entry Point for functions.
> LEP catches call from both the GEP and the LEP. Symbol table of ELF
> contains GEP and Offset from which we can calculate LEP, but debuginfo
> does not have LEP info.
> 
> Currently, perf prioritize symbol table over dwarf to probe on LEP
> for ppc64le. But when user tries to probe with function parameter,
> we fall back to using dwarf(i.e. GEP) and when function called via
> LEP, probe will never hit.

This patch causes a build failure for me on ppc64le:

libperf.a(libperf-in.o): In function `arch__post_process_probe_trace_events':

tools/perf/arch/powerpc/util/sym-handling.c:109: undefined reference to 
`get_target_map'

Anton

> For example:
>   $ objdump -d vmlinux
> ...
> do_sys_open():
> c02eb4a0:   e8 00 4c 3c addis   r2,r12,232
> c02eb4a4:   60 00 42 38 addir2,r2,96
> c02eb4a8:   a6 02 08 7c mflrr0
> c02eb4ac:   d0 ff 41 fb std r26,-48(r1)
> 
>   $ sudo ./perf probe do_sys_open
>   $ sudo cat /sys/kernel/debug/tracing/kprobe_events
> p:probe/do_sys_open _text+3060904
> 
>   $ sudo ./perf probe 'do_sys_open filename:string'
>   $ sudo cat /sys/kernel/debug/tracing/kprobe_events
> p:probe/do_sys_open _text+3060896 filename_string=+0(%gpr4):string
> 
> For second case, perf probed on GEP. So when function will be called
> via LEP, probe won't hit.
> 
>   $ sudo ./perf record -a -e probe:do_sys_open ls
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.195 MB perf.data ]
> 
> To resolve this issue, let's not prioritize symbol table, let perf
> decide what it wants to use. Perf is already converting GEP to LEP
> when it uses symbol table. When perf uses debuginfo, let it find
> LEP offset form symbol table. This way we fall back to probe on LEP
> for all cases.
> 
> After patch:
>   $ sudo ./perf probe 'do_sys_open filename:string'
>   $ sudo cat /sys/kernel/debug/tracing/kprobe_events
> p:probe/do_sys_open _text+3060904 filename_string=+0(%gpr4):string
> 
>   $ sudo ./perf record -a -e probe:do_sys_open ls
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.197 MB perf.data (11 samples)
> ]
> 
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/perf/arch/powerpc/util/sym-handling.c | 27
> + tools/perf/util/probe-event.c   |
> 37 -
> tools/perf/util/probe-event.h   |  6 - 3 files
> changed, 49 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
> b/tools/perf/arch/powerpc/util/sym-handling.c index c6d0f91..8d4dc97
> 100644 --- a/tools/perf/arch/powerpc/util/sym-handling.c
> +++ b/tools/perf/arch/powerpc/util/sym-handling.c
> @@ -54,10 +54,6 @@ int arch__compare_symbol_names(const char *namea,
> const char *nameb) #endif
>  
>  #if defined(_CALL_ELF) && _CALL_ELF == 2
> -bool arch__prefers_symtab(void)
> -{
> - return true;
> -}
>  
>  #ifdef HAVE_LIBELF_SUPPORT
>  void arch__sym_update(struct symbol *s, GElf_Sym *sym)
> @@ -100,4 +96,27 @@ void arch__fix_tev_from_maps(struct
> perf_probe_event *pev, tev->point.offset += lep_offset;
>   }
>  }
> +
> +void arch__post_process_probe_trace_events(struct perf_probe_event
> *pev,
> +int ntevs)
> +{
> + struct probe_trace_event *tev;
> + struct map *map;
> + struct symbol *sym = NULL;
> + struct rb_node *tmp;
> + int i = 0;
> +
> + map = get_target_map(pev->target, pev->uprobes);
> + if (!map || map__load(map, NULL) < 0)
> + return;
> +
> + for (i = 0; i < ntevs; i++) {
> + tev = >tevs[i];
> + map__for_each_symbol(map, sym, tmp) {
> + if (map->unmap_ip(map, sym->start) ==
> tev->point.address)
> + arch__fix_tev_from_maps(pev, tev,
> map, sym);
> + }
> + }
> +}
> +
>  #endif
> diff --git a/tools/perf/util/probe-event.c
> b/tools/perf/util/probe-event.c index 4e215e7..5efa535 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -178,7 +178,7 @@ static struct map *kernel_get_module_map(const
> char *module) return NULL;
>  }
>  
> -static struct map *get_target_map(const char *target, bool user)
> +struct map *get_target_map(const char *target, bool user)
>  {
>   /* Init maps of given executable or kernel */
>   if (user)
> @@ -703,19 +703,32 @@ post_process_kernel_probe_trace_events(struct
> probe_trace_event *tevs, return skipped;
>  }
>  
> +void __weak
> +arch__post_process_probe_trace_events(struct perf_probe_event *pev
> __maybe_unused,
> +   int ntevs __maybe_unused)
> +{
> +}
> +
>  /* Post processing the probe events */
> -static int post_process_probe_trace_events(struct

Re: [PATCH 2/2] perf ppc64le: Fix probe location when using DWARF

2016-08-10 Thread Anton Blanchard

Hi,

> Powerpc has Global Entry Point and Local Entry Point for functions.
> LEP catches call from both the GEP and the LEP. Symbol table of ELF
> contains GEP and Offset from which we can calculate LEP, but debuginfo
> does not have LEP info.
> 
> Currently, perf prioritize symbol table over dwarf to probe on LEP
> for ppc64le. But when user tries to probe with function parameter,
> we fall back to using dwarf(i.e. GEP) and when function called via
> LEP, probe will never hit.

This patch causes a build failure for me on ppc64le:

libperf.a(libperf-in.o): In function `arch__post_process_probe_trace_events':

tools/perf/arch/powerpc/util/sym-handling.c:109: undefined reference to 
`get_target_map'

Anton

> For example:
>   $ objdump -d vmlinux
> ...
> do_sys_open():
> c02eb4a0:   e8 00 4c 3c addis   r2,r12,232
> c02eb4a4:   60 00 42 38 addir2,r2,96
> c02eb4a8:   a6 02 08 7c mflrr0
> c02eb4ac:   d0 ff 41 fb std r26,-48(r1)
> 
>   $ sudo ./perf probe do_sys_open
>   $ sudo cat /sys/kernel/debug/tracing/kprobe_events
> p:probe/do_sys_open _text+3060904
> 
>   $ sudo ./perf probe 'do_sys_open filename:string'
>   $ sudo cat /sys/kernel/debug/tracing/kprobe_events
> p:probe/do_sys_open _text+3060896 filename_string=+0(%gpr4):string
> 
> For second case, perf probed on GEP. So when function will be called
> via LEP, probe won't hit.
> 
>   $ sudo ./perf record -a -e probe:do_sys_open ls
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.195 MB perf.data ]
> 
> To resolve this issue, let's not prioritize symbol table, let perf
> decide what it wants to use. Perf is already converting GEP to LEP
> when it uses symbol table. When perf uses debuginfo, let it find
> LEP offset form symbol table. This way we fall back to probe on LEP
> for all cases.
> 
> After patch:
>   $ sudo ./perf probe 'do_sys_open filename:string'
>   $ sudo cat /sys/kernel/debug/tracing/kprobe_events
> p:probe/do_sys_open _text+3060904 filename_string=+0(%gpr4):string
> 
>   $ sudo ./perf record -a -e probe:do_sys_open ls
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.197 MB perf.data (11 samples)
> ]
> 
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/perf/arch/powerpc/util/sym-handling.c | 27
> + tools/perf/util/probe-event.c   |
> 37 -
> tools/perf/util/probe-event.h   |  6 - 3 files
> changed, 49 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
> b/tools/perf/arch/powerpc/util/sym-handling.c index c6d0f91..8d4dc97
> 100644 --- a/tools/perf/arch/powerpc/util/sym-handling.c
> +++ b/tools/perf/arch/powerpc/util/sym-handling.c
> @@ -54,10 +54,6 @@ int arch__compare_symbol_names(const char *namea,
> const char *nameb) #endif
>  
>  #if defined(_CALL_ELF) && _CALL_ELF == 2
> -bool arch__prefers_symtab(void)
> -{
> - return true;
> -}
>  
>  #ifdef HAVE_LIBELF_SUPPORT
>  void arch__sym_update(struct symbol *s, GElf_Sym *sym)
> @@ -100,4 +96,27 @@ void arch__fix_tev_from_maps(struct
> perf_probe_event *pev, tev->point.offset += lep_offset;
>   }
>  }
> +
> +void arch__post_process_probe_trace_events(struct perf_probe_event
> *pev,
> +int ntevs)
> +{
> + struct probe_trace_event *tev;
> + struct map *map;
> + struct symbol *sym = NULL;
> + struct rb_node *tmp;
> + int i = 0;
> +
> + map = get_target_map(pev->target, pev->uprobes);
> + if (!map || map__load(map, NULL) < 0)
> + return;
> +
> + for (i = 0; i < ntevs; i++) {
> + tev = >tevs[i];
> + map__for_each_symbol(map, sym, tmp) {
> + if (map->unmap_ip(map, sym->start) ==
> tev->point.address)
> + arch__fix_tev_from_maps(pev, tev,
> map, sym);
> + }
> + }
> +}
> +
>  #endif
> diff --git a/tools/perf/util/probe-event.c
> b/tools/perf/util/probe-event.c index 4e215e7..5efa535 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -178,7 +178,7 @@ static struct map *kernel_get_module_map(const
> char *module) return NULL;
>  }
>  
> -static struct map *get_target_map(const char *target, bool user)
> +struct map *get_target_map(const char *target, bool user)
>  {
>   /* Init maps of given executable or kernel */
>   if (user)
> @@ -703,19 +703,32 @@ post_process_kernel_probe_trace_events(struct
> probe_trace_event *tevs, return skipped;
>  }
>  
> +void __weak
> +arch__post_process_probe_trace_events(struct perf_probe_event *pev
> __maybe_unused,
> +   int ntevs __maybe_unused)
> +{
> +}
> +
>  /* Post processing the probe events */
> -static int post_process_probe_trace_events(struct probe_trace_event
> *tevs, +static int

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

2016-07-15 Thread Anton Blanchard


> > I noticed tip started failing in my CI environment which tests on
> > QEMU. The failure bisected to commit
> > 425209e0abaf2c6e3a90ce4fedb935c10652bf80  
> 
> That's very useful, thanks Anton!
> 
> I have removed this commit from the series for the time being,
> refactored the followup commits (there was one trivial conflict). We
> can re-try this patch when a fix is found.

Thanks Ingo, my tests are passing again after your last push.

Anton

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

2016-07-15 Thread Anton Blanchard


> > I noticed tip started failing in my CI environment which tests on
> > QEMU. The failure bisected to commit
> > 425209e0abaf2c6e3a90ce4fedb935c10652bf80  
> 
> That's very useful, thanks Anton!
> 
> I have removed this commit from the series for the time being,
> refactored the followup commits (there was one trivial conflict). We
> can re-try this patch when a fix is found.

Thanks Ingo, my tests are passing again after your last push.

Anton

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

2016-07-14 Thread Anton Blanchard

Hi Anna-Maria,

> >> Install the callbacks via the state machine and let the core invoke
> >> the callbacks on the already online CPUs.  
> >
> > This is causing an oops on ppc64le QEMU, looks like a NULL
> > pointer:  
> 
> Did you tested it against tip WIP.hotplug?

I noticed tip started failing in my CI environment which tests on QEMU.
The failure bisected to commit 425209e0abaf2c6e3a90ce4fedb935c10652bf80

It reproduces running ppc64le QEMU on a x86-64 box. On Ubuntu:

sudo apt-get install qemu-system-ppc gcc-powerpc64le-linux-gnu

make ARCH=powerpc pseries_le_defconfig

make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- vmlinux -j4

qemu-system-ppc64 -nographic -vga none -kernel vmlinux 

Anton

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

2016-07-14 Thread Anton Blanchard

Hi Anna-Maria,

> >> Install the callbacks via the state machine and let the core invoke
> >> the callbacks on the already online CPUs.  
> >
> > This is causing an oops on ppc64le QEMU, looks like a NULL
> > pointer:  
> 
> Did you tested it against tip WIP.hotplug?

I noticed tip started failing in my CI environment which tests on QEMU.
The failure bisected to commit 425209e0abaf2c6e3a90ce4fedb935c10652bf80

It reproduces running ppc64le QEMU on a x86-64 box. On Ubuntu:

sudo apt-get install qemu-system-ppc gcc-powerpc64le-linux-gnu

make ARCH=powerpc pseries_le_defconfig

make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- vmlinux -j4

qemu-system-ppc64 -nographic -vga none -kernel vmlinux 

Anton

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

2016-07-14 Thread Anton Blanchard

Hi,

> From: Sebastian Andrzej Siewior 
> 
> Install the callbacks via the state machine and let the core invoke
> the callbacks on the already online CPUs.

This is causing an oops on ppc64le QEMU, looks like a NULL pointer:

percpu: Embedded 3 pages/cpu @c0001fe0 s145816 r0 d50792 u1048576
Unable to handle kernel paging request for data at address 0x1e08
Faulting instruction address: 0xc01e6b78
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc7-00198-g425209e #14
task: c0d82a00 ti: c0dc4000 task.ti: c0dc4000
NIP: c01e6b78 LR: c01e6df4 CTR: 
REGS: c0dc7b60 TRAP: 0300   Not tainted  (4.7.0-rc7-00198-g425209e)
MSR: 82001033   CR: 44000220  XER: 
CFAR: 8468 DAR: 1e08 DSISR: 4000 SOFTE: 0 
GPR00: 0006 c0dc7de0 c0dc6c00  
GPR04:   c0001fe1fb70 0010 
GPR08: c0dfe918 c0e50dd0 c0e56c00 0001 
GPR12:  cfe0 0060 00f1d618 
GPR16: 00efccd8 00efcb20 fffd  
GPR20: 1f15 c0dfa8e0 c0ccfafc c0dfeb18 
GPR24: c0dfee34 c0ccfaf8  0001 
GPR28: c0ebad20 c0ccfb00  c0001fe1fb00 
NIP [c01e6b78] local_memory_node+0x18/0x80
LR [c01e6df4] __build_all_zonelists+0x214/0x2d0
Call Trace:
[c0dc7de0] [c01e6ccc] __build_all_zonelists+0xec/0x2d0 
(unreliable)
[c0dc7e70] [c0c39fbc] build_all_zonelists_init+0x1c/0x3c
[c0dc7e90] [c0282acc] build_all_zonelists+0x17c/0x18c
[c0dc7f00] [c0c13c54] start_kernel+0x18c/0x514
[c0dc7f90] [c0008c60] start_here_common+0x20/0xa0
Instruction dump:
38810178 7f63db78 48769171 6000 4bfffd2c 6042 3c4c00be 384200a0 
3d420009 78631f24 392aa1d0 7c69182a <81231e08> 38631e00 2b890002 419d001c 

Anton

> Signed-off-by: Sebastian Andrzej Siewior 
> Cc: Andrew Morton 
> Cc: Benjamin Herrenschmidt 
> Cc: Bharata B Rao 
> Cc: Christophe Jaillet 
> Cc: Linus Torvalds 
> Cc: Michael Ellerman 
> Cc: Nikunj A Dadhania 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Raghavendra K T 
> Cc: Thomas Gleixner 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Anna-Maria Gleixner 
> ---
>  arch/powerpc/mm/numa.c | 46
> --
> include/linux/cpuhotplug.h |  1 + 2 files changed, 17 insertions(+),
> 30 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 669a15e..d48ac48 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -581,30 +581,22 @@ static void verify_cpu_node_mapping(int cpu,
> int node) }
>  }
>  
> -static int cpu_numa_callback(struct notifier_block *nfb, unsigned
> long action,
> -  void *hcpu)
> +/* Must run before sched domains notifier. */
> +static int ppc_numa_cpu_prepare(unsigned int cpu)
>  {
> - unsigned long lcpu = (unsigned long)hcpu;
> - int ret = NOTIFY_DONE, nid;
> + int nid;
>  
> - switch (action) {
> - case CPU_UP_PREPARE:
> - case CPU_UP_PREPARE_FROZEN:
> - nid = numa_setup_cpu(lcpu);
> - verify_cpu_node_mapping((int)lcpu, nid);
> - ret = NOTIFY_OK;
> - break;
> + nid = numa_setup_cpu(cpu);
> + verify_cpu_node_mapping(cpu, nid);
> + return 0;
> +}
> +
> +static int ppc_numa_cpu_dead(unsigned int cpu)
> +{
>  #ifdef CONFIG_HOTPLUG_CPU
> - case CPU_DEAD:
> - case CPU_DEAD_FROZEN:
> - case CPU_UP_CANCELED:
> - case CPU_UP_CANCELED_FROZEN:
> - unmap_cpu_from_node(lcpu);
> - ret = NOTIFY_OK;
> - break;
> + unmap_cpu_from_node(cpu);
>  #endif
> - }
> - return ret;
> + return 0;
>  }
>  
>  /*
> @@ -913,11 +905,6 @@ static void __init
> dump_numa_memory_topology(void) }
>  }
>  
> -static struct notifier_block ppc64_numa_nb = {
> - .notifier_call = cpu_numa_callback,
> - .priority = 1 /* Must run before sched domains notifier. */
> -};
> -
>  /* Initialize NODE_DATA for a node on the local memory */
>  static void __init setup_node_data(int nid, u64 start_pfn, u64
> end_pfn) {
> @@ -953,7 +940,7 @@ static void __init setup_node_data(int nid, u64
> start_pfn, u64 end_pfn) 
>  void __init initmem_init(void)
>

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

2016-07-14 Thread Anton Blanchard

Hi,

> From: Sebastian Andrzej Siewior 
> 
> Install the callbacks via the state machine and let the core invoke
> the callbacks on the already online CPUs.

This is causing an oops on ppc64le QEMU, looks like a NULL pointer:

percpu: Embedded 3 pages/cpu @c0001fe0 s145816 r0 d50792 u1048576
Unable to handle kernel paging request for data at address 0x1e08
Faulting instruction address: 0xc01e6b78
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc7-00198-g425209e #14
task: c0d82a00 ti: c0dc4000 task.ti: c0dc4000
NIP: c01e6b78 LR: c01e6df4 CTR: 
REGS: c0dc7b60 TRAP: 0300   Not tainted  (4.7.0-rc7-00198-g425209e)
MSR: 82001033   CR: 44000220  XER: 
CFAR: 8468 DAR: 1e08 DSISR: 4000 SOFTE: 0 
GPR00: 0006 c0dc7de0 c0dc6c00  
GPR04:   c0001fe1fb70 0010 
GPR08: c0dfe918 c0e50dd0 c0e56c00 0001 
GPR12:  cfe0 0060 00f1d618 
GPR16: 00efccd8 00efcb20 fffd  
GPR20: 1f15 c0dfa8e0 c0ccfafc c0dfeb18 
GPR24: c0dfee34 c0ccfaf8  0001 
GPR28: c0ebad20 c0ccfb00  c0001fe1fb00 
NIP [c01e6b78] local_memory_node+0x18/0x80
LR [c01e6df4] __build_all_zonelists+0x214/0x2d0
Call Trace:
[c0dc7de0] [c01e6ccc] __build_all_zonelists+0xec/0x2d0 
(unreliable)
[c0dc7e70] [c0c39fbc] build_all_zonelists_init+0x1c/0x3c
[c0dc7e90] [c0282acc] build_all_zonelists+0x17c/0x18c
[c0dc7f00] [c0c13c54] start_kernel+0x18c/0x514
[c0dc7f90] [c0008c60] start_here_common+0x20/0xa0
Instruction dump:
38810178 7f63db78 48769171 6000 4bfffd2c 6042 3c4c00be 384200a0 
3d420009 78631f24 392aa1d0 7c69182a <81231e08> 38631e00 2b890002 419d001c 

Anton

> Signed-off-by: Sebastian Andrzej Siewior 
> Cc: Andrew Morton 
> Cc: Benjamin Herrenschmidt 
> Cc: Bharata B Rao 
> Cc: Christophe Jaillet 
> Cc: Linus Torvalds 
> Cc: Michael Ellerman 
> Cc: Nikunj A Dadhania 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Raghavendra K T 
> Cc: Thomas Gleixner 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Anna-Maria Gleixner 
> ---
>  arch/powerpc/mm/numa.c | 46
> --
> include/linux/cpuhotplug.h |  1 + 2 files changed, 17 insertions(+),
> 30 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 669a15e..d48ac48 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -581,30 +581,22 @@ static void verify_cpu_node_mapping(int cpu,
> int node) }
>  }
>  
> -static int cpu_numa_callback(struct notifier_block *nfb, unsigned
> long action,
> -  void *hcpu)
> +/* Must run before sched domains notifier. */
> +static int ppc_numa_cpu_prepare(unsigned int cpu)
>  {
> - unsigned long lcpu = (unsigned long)hcpu;
> - int ret = NOTIFY_DONE, nid;
> + int nid;
>  
> - switch (action) {
> - case CPU_UP_PREPARE:
> - case CPU_UP_PREPARE_FROZEN:
> - nid = numa_setup_cpu(lcpu);
> - verify_cpu_node_mapping((int)lcpu, nid);
> - ret = NOTIFY_OK;
> - break;
> + nid = numa_setup_cpu(cpu);
> + verify_cpu_node_mapping(cpu, nid);
> + return 0;
> +}
> +
> +static int ppc_numa_cpu_dead(unsigned int cpu)
> +{
>  #ifdef CONFIG_HOTPLUG_CPU
> - case CPU_DEAD:
> - case CPU_DEAD_FROZEN:
> - case CPU_UP_CANCELED:
> - case CPU_UP_CANCELED_FROZEN:
> - unmap_cpu_from_node(lcpu);
> - ret = NOTIFY_OK;
> - break;
> + unmap_cpu_from_node(cpu);
>  #endif
> - }
> - return ret;
> + return 0;
>  }
>  
>  /*
> @@ -913,11 +905,6 @@ static void __init
> dump_numa_memory_topology(void) }
>  }
>  
> -static struct notifier_block ppc64_numa_nb = {
> - .notifier_call = cpu_numa_callback,
> - .priority = 1 /* Must run before sched domains notifier. */
> -};
> -
>  /* Initialize NODE_DATA for a node on the local memory */
>  static void __init setup_node_data(int nid, u64 start_pfn, u64
> end_pfn) {
> @@ -953,7 +940,7 @@ static void __init setup_node_data(int nid, u64
> start_pfn, u64 end_pfn) 
>  void __init initmem_init(void)
>  {
> - int nid, cpu;
> + int nid;
>  
>   max_low_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
>   max_pfn = max_low_pfn;
> @@ -985,15 +972,14 @@ void __init initmem_init(void)
>   setup_node_to_cpumask_map();
>  
>   reset_numa_cpu_lookup_table();
> - register_cpu_notifier(_numa_nb);
> +
>   /*
>* We need the numa_cpu_lookup_table to be

Re: [patch 10/15] sched/migration: Move calc_load_migrate() into CPU_DYING

2016-07-11 Thread Anton Blanchard

Hi Thomas,

> It really does not matter when we fold the load for the outgoing cpu.
> It's almost dead anyway, so there is no harm if we fail to fold the
> few microseconds which are required for going fully away.

We are seeing the load average shoot up when hot unplugging CPUs (+1
for every CPU we offline) on ppc64. This reproduces on bare metal as
well as inside a KVM guest. A bisect points at this commit.

As an example, a completely idle box with 128 CPUS and 112 hot
unplugged:

# uptime
 04:35:30 up  1:23,  2 users,  load average: 112.43, 122.94, 125.54

Anton

Re: [patch 10/15] sched/migration: Move calc_load_migrate() into CPU_DYING

2016-07-11 Thread Anton Blanchard

Hi Thomas,

> It really does not matter when we fold the load for the outgoing cpu.
> It's almost dead anyway, so there is no harm if we fail to fold the
> few microseconds which are required for going fully away.

We are seeing the load average shoot up when hot unplugging CPUs (+1
for every CPU we offline) on ppc64. This reproduces on bare metal as
well as inside a KVM guest. A bisect points at this commit.

As an example, a completely idle box with 128 CPUS and 112 hot
unplugged:

# uptime
 04:35:30 up  1:23,  2 users,  load average: 112.43, 122.94, 125.54

Anton

[PATCH 1/2] exit: Quieten greatest stack depth printk

2016-06-26 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

Many targets enable CONFIG_DEBUG_STACK_USAGE, and while the information
is useful, it isn't worthy of pr_warn(). Reduce it to pr_info().

Signed-off-by: Anton Blanchard <an...@samba.org>
---
 kernel/exit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 9e6e135..bbdef62 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -639,7 +639,7 @@ static void check_stack_usage(void)
 
spin_lock(_water_lock);
if (free < lowest_to_date) {
-   pr_warn("%s (%d) used greatest stack depth: %lu bytes left\n",
+   pr_info("%s (%d) used greatest stack depth: %lu bytes left\n",
current->comm, task_pid_nr(current), free);
lowest_to_date = free;
}
-- 
2.7.4

[PATCH 2/2] mm: workingset: printk missing log level, use pr_info()

2016-06-26 Thread Anton Blanchard

From: Anton Blanchard <an...@samba.org>

commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit
machines") added a printk without a log level. Quieten it by using
pr_info().

Signed-off-by: Anton Blanchard <an...@samba.org>
---
 mm/workingset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index 8a75f8d..5772775 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -491,7 +491,7 @@ static int __init workingset_init(void)
max_order = fls_long(totalram_pages - 1);
if (max_order > timestamp_bits)
bucket_order = max_order - timestamp_bits;
-   printk("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
+   pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
   timestamp_bits, max_order, bucket_order);
 
ret = list_lru_init_key(_shadow_nodes, _nodes_key);
-- 
2.7.4

[PATCH 1/2] exit: Quieten greatest stack depth printk

2016-06-26 Thread Anton Blanchard

From: Anton Blanchard 

Many targets enable CONFIG_DEBUG_STACK_USAGE, and while the information
is useful, it isn't worthy of pr_warn(). Reduce it to pr_info().

Signed-off-by: Anton Blanchard 
---
 kernel/exit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 9e6e135..bbdef62 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -639,7 +639,7 @@ static void check_stack_usage(void)
 
spin_lock(_water_lock);
if (free < lowest_to_date) {
-   pr_warn("%s (%d) used greatest stack depth: %lu bytes left\n",
+   pr_info("%s (%d) used greatest stack depth: %lu bytes left\n",
current->comm, task_pid_nr(current), free);
lowest_to_date = free;
}
-- 
2.7.4

[PATCH 2/2] mm: workingset: printk missing log level, use pr_info()

2016-06-26 Thread Anton Blanchard

From: Anton Blanchard 

commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit
machines") added a printk without a log level. Quieten it by using
pr_info().

Signed-off-by: Anton Blanchard 
---
 mm/workingset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index 8a75f8d..5772775 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -491,7 +491,7 @@ static int __init workingset_init(void)
max_order = fls_long(totalram_pages - 1);
if (max_order > timestamp_bits)
bucket_order = max_order - timestamp_bits;
-   printk("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
+   pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
   timestamp_bits, max_order, bucket_order);
 
ret = list_lru_init_key(_shadow_nodes, _nodes_key);
-- 
2.7.4

Re: [PATCH] powerpc: inline current_stack_pointer()

2016-05-31 Thread Anton Blanchard

Hi,

> current_stack_pointeur() is a single instruction function. it
> It is not worth breaking the execution flow with a bl/blr for a
> single instruction

Check out bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a function
not a define") to see why we made it a function.

Anton

Re: [PATCH] powerpc: inline current_stack_pointer()

2016-05-31 Thread Anton Blanchard

Hi,

> current_stack_pointeur() is a single instruction function. it
> It is not worth breaking the execution flow with a bl/blr for a
> single instruction

Check out bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a function
not a define") to see why we made it a function.

Anton

[tip:sched/core] sched/cpuacct: Check for NULL when using task_pt_regs()

2016-04-13 Thread tip-bot for Anton Blanchard

Commit-ID:  bd92883051a0228cc34996b8e766111ba10c9aac
Gitweb: http://git.kernel.org/tip/bd92883051a0228cc34996b8e766111ba10c9aac
Author: Anton Blanchard <an...@samba.org>
AuthorDate: Wed, 6 Apr 2016 21:59:50 +1000
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Wed, 13 Apr 2016 13:22:37 +0200

sched/cpuacct: Check for NULL when using task_pt_regs()

task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.

Reported-and-Tested-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
Tested-by: Zhao Lei <zhao...@cn.fujitsu.com>
Signed-off-by: Anton Blanchard <an...@samba.org>
Acked-by: Zhao Lei <zhao...@cn.fujitsu.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Stephen Rothwell <s...@canb.auug.org.au>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: efa...@gmx.de
Cc: hte...@gmail.com
Cc: linuxppc-...@lists.ozlabs.org
Cc: t...@kernel.org
Cc: yangds.f...@cn.fujitsu.com
Link: http://lkml.kernel.org/r/20160406215950.04bc3f0b@kryten
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 kernel/sched/cpuacct.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index df947e0..41f85c4 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -316,12 +316,11 @@ static struct cftype files[] = {
 void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 {
struct cpuacct *ca;
-   int index;
+   int index = CPUACCT_USAGE_SYSTEM;
+   struct pt_regs *regs = task_pt_regs(tsk);
 
-   if (user_mode(task_pt_regs(tsk)))
+   if (regs && user_mode(regs))
index = CPUACCT_USAGE_USER;
-   else
-   index = CPUACCT_USAGE_SYSTEM;
 
rcu_read_lock();

[tip:sched/core] sched/cpuacct: Check for NULL when using task_pt_regs()

2016-04-13 Thread tip-bot for Anton Blanchard

Commit-ID:  bd92883051a0228cc34996b8e766111ba10c9aac
Gitweb: http://git.kernel.org/tip/bd92883051a0228cc34996b8e766111ba10c9aac
Author: Anton Blanchard 
AuthorDate: Wed, 6 Apr 2016 21:59:50 +1000
Committer:  Ingo Molnar 
CommitDate: Wed, 13 Apr 2016 13:22:37 +0200

sched/cpuacct: Check for NULL when using task_pt_regs()

task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.

Reported-and-Tested-by: Srikar Dronamraju 
Tested-by: Zhao Lei 
Signed-off-by: Anton Blanchard 
Acked-by: Zhao Lei 
Cc: Linus Torvalds 
Cc: Michael Ellerman 
Cc: Peter Zijlstra 
Cc: Stephen Rothwell 
Cc: Thomas Gleixner 
Cc: efa...@gmx.de
Cc: hte...@gmail.com
Cc: linuxppc-...@lists.ozlabs.org
Cc: t...@kernel.org
Cc: yangds.f...@cn.fujitsu.com
Link: http://lkml.kernel.org/r/20160406215950.04bc3f0b@kryten
Signed-off-by: Ingo Molnar 
---
 kernel/sched/cpuacct.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index df947e0..41f85c4 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -316,12 +316,11 @@ static struct cftype files[] = {
 void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 {
struct cpuacct *ca;
-   int index;
+   int index = CPUACCT_USAGE_SYSTEM;
+   struct pt_regs *regs = task_pt_regs(tsk);
 
-   if (user_mode(task_pt_regs(tsk)))
+   if (regs && user_mode(regs))
index = CPUACCT_USAGE_USER;
-   else
-   index = CPUACCT_USAGE_SYSTEM;
 
rcu_read_lock();

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

2016-04-13 Thread Anton Blanchard

task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.

Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and 
sys_usage")
Signed-off-by: Anton Blanchard <an...@samba.org>
Reported-and-Tested-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com>
---

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index df947e0..41f85c4 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -316,12 +316,11 @@ static struct cftype files[] = {
 void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 {
struct cpuacct *ca;
-   int index;
+   int index = CPUACCT_USAGE_SYSTEM;
+   struct pt_regs *regs = task_pt_regs(tsk);
 
-   if (user_mode(task_pt_regs(tsk)))
+   if (regs && user_mode(regs))
index = CPUACCT_USAGE_USER;
-   else
-   index = CPUACCT_USAGE_SYSTEM;
 
rcu_read_lock();

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

2016-04-13 Thread Anton Blanchard

task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.

Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and 
sys_usage")
Signed-off-by: Anton Blanchard 
Reported-and-Tested-by: Srikar Dronamraju 
---

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index df947e0..41f85c4 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -316,12 +316,11 @@ static struct cftype files[] = {
 void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 {
struct cpuacct *ca;
-   int index;
+   int index = CPUACCT_USAGE_SYSTEM;
+   struct pt_regs *regs = task_pt_regs(tsk);
 
-   if (user_mode(task_pt_regs(tsk)))
+   if (regs && user_mode(regs))
index = CPUACCT_USAGE_USER;
-   else
-   index = CPUACCT_USAGE_SYSTEM;
 
rcu_read_lock();

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

2016-04-06 Thread Anton Blanchard

Hi Peter,

> Ah, so sometihng like:
> 
>   struct pt_regs *regs = task_pt_regs();
>   int index = CPUACCT_USAGE_SYSTEM;
> 
>   if (regs && user_mode(regs))
>   index = CPUACCT_USAGE_USER;
> 
> should work, right?

Looks good, and the patch below does fix the oops for me.

Anton
--

task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.

Signed-off-by: Anton Blanchard <an...@samba.org>
---

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index df947e0..41f85c4 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -316,12 +316,11 @@ static struct cftype files[] = {
 void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 {
struct cpuacct *ca;
-   int index;
+   int index = CPUACCT_USAGE_SYSTEM;
+   struct pt_regs *regs = task_pt_regs(tsk);
 
-   if (user_mode(task_pt_regs(tsk)))
+   if (regs && user_mode(regs))
index = CPUACCT_USAGE_USER;
-   else
-   index = CPUACCT_USAGE_SYSTEM;
 
rcu_read_lock();

[PATCH] sched/cpuacct: Check for NULL when using task_pt_regs()

2016-04-06 Thread Anton Blanchard

Hi Peter,

> Ah, so sometihng like:
> 
>   struct pt_regs *regs = task_pt_regs();
>   int index = CPUACCT_USAGE_SYSTEM;
> 
>   if (regs && user_mode(regs))
>   index = CPUACCT_USAGE_USER;
> 
> should work, right?

Looks good, and the patch below does fix the oops for me.

Anton
--

task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.

Signed-off-by: Anton Blanchard 
---

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index df947e0..41f85c4 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -316,12 +316,11 @@ static struct cftype files[] = {
 void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 {
struct cpuacct *ca;
-   int index;
+   int index = CPUACCT_USAGE_SYSTEM;
+   struct pt_regs *regs = task_pt_regs(tsk);
 
-   if (user_mode(task_pt_regs(tsk)))
+   if (regs && user_mode(regs))
index = CPUACCT_USAGE_USER;
-   else
-   index = CPUACCT_USAGE_SYSTEM;
 
rcu_read_lock();

Re: [tip:sched/core] sched/cpuacct: Split usage accounting into user_usage and sys_usage

2016-04-06 Thread Anton Blanchard

Hi,

> > >  void cpuacct_charge(struct task_struct *tsk, u64 cputime)
> > >  {
> > >   struct cpuacct *ca;
> > > + int index;
> > > +
> > > + if (user_mode(task_pt_regs(tsk)))
> > > + index = CPUACCT_USAGE_USER;
> > > + else
> > > + index = CPUACCT_USAGE_SYSTEM;

This is oopsing because PowerPC task_pt_regs() returns NULL for
kernel threads.

Anton

Re: [tip:sched/core] sched/cpuacct: Split usage accounting into user_usage and sys_usage

2016-04-06 Thread Anton Blanchard

Hi,

> > >  void cpuacct_charge(struct task_struct *tsk, u64 cputime)
> > >  {
> > >   struct cpuacct *ca;
> > > + int index;
> > > +
> > > + if (user_mode(task_pt_regs(tsk)))
> > > + index = CPUACCT_USAGE_USER;
> > > + else
> > > + index = CPUACCT_USAGE_SYSTEM;

This is oopsing because PowerPC task_pt_regs() returns NULL for
kernel threads.

Anton

[tip:perf/urgent] perf jit: genelf makes assumptions about endian

2016-03-31 Thread tip-bot for Anton Blanchard

Commit-ID:  9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6
Gitweb: http://git.kernel.org/tip/9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6
Author: Anton Blanchard <an...@samba.org>
AuthorDate: Tue, 29 Mar 2016 17:59:44 +1100
Committer:  Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Wed, 30 Mar 2016 18:12:06 -0300

perf jit: genelf makes assumptions about endian

Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
incorrectly assumed that PowerPC is big endian only.

Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking
for __BYTE_ORDER == __BIG_ENDIAN.

The PowerPC checks were also incorrect, they do not match what gcc
emits. We should first look for __powerpc64__, then __powerpc__.

Signed-off-by: Anton Blanchard <an...@samba.org>
Acked-by: Michael Ellerman <m...@ellerman.id.au>
Cc: Carl Love <c...@us.ibm.com>
Cc: Stephane Eranian <eran...@google.com>
Cc: Sukadev Bhattiprolu <suka...@linux.vnet.ibm.com>
Cc: linuxppc-...@lists.ozlabs.org
Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
Link: http://lkml.kernel.org/r/20160329175944.33a211cc@kryten
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
 tools/perf/util/genelf.h | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/tools/perf/util/genelf.h b/tools/perf/util/genelf.h
index cd67e64..2fbeb59 100644
--- a/tools/perf/util/genelf.h
+++ b/tools/perf/util/genelf.h
@@ -9,36 +9,32 @@ int jit_add_debug_info(Elf *e, uint64_t code_addr, void 
*debug, int nr_debug_ent
 
 #if   defined(__arm__)
 #define GEN_ELF_ARCH   EM_ARM
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
 #elif defined(__aarch64__)
 #define GEN_ELF_ARCH   EM_AARCH64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__x86_64__)
 #define GEN_ELF_ARCH   EM_X86_64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__i386__)
 #define GEN_ELF_ARCH   EM_386
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
-#elif defined(__ppcle__)
-#define GEN_ELF_ARCH   EM_PPC
-#define GEN_ELF_ENDIAN ELFDATA2LSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpc__)
-#define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2MSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpcle__)
+#elif defined(__powerpc64__)
 #define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
+#elif defined(__powerpc__)
+#define GEN_ELF_ARCH   EM_PPC
+#define GEN_ELF_CLASS  ELFCLASS32
 #else
 #error "unsupported architecture"
 #endif
 
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define GEN_ELF_ENDIAN ELFDATA2MSB
+#else
+#define GEN_ELF_ENDIAN ELFDATA2LSB
+#endif
+
 #if GEN_ELF_CLASS == ELFCLASS64
 #define elf_newehdrelf64_newehdr
 #define elf_getshdrelf64_getshdr

[tip:perf/urgent] perf jit: genelf makes assumptions about endian

2016-03-31 Thread tip-bot for Anton Blanchard

Commit-ID:  9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6
Gitweb: http://git.kernel.org/tip/9f56c092b99b40ce3cf4c6d0134ff7e513c9f1a6
Author: Anton Blanchard 
AuthorDate: Tue, 29 Mar 2016 17:59:44 +1100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 30 Mar 2016 18:12:06 -0300

perf jit: genelf makes assumptions about endian

Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
incorrectly assumed that PowerPC is big endian only.

Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking
for __BYTE_ORDER == __BIG_ENDIAN.

The PowerPC checks were also incorrect, they do not match what gcc
emits. We should first look for __powerpc64__, then __powerpc__.

Signed-off-by: Anton Blanchard 
Acked-by: Michael Ellerman 
Cc: Carl Love 
Cc: Stephane Eranian 
Cc: Sukadev Bhattiprolu 
Cc: linuxppc-...@lists.ozlabs.org
Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
Link: http://lkml.kernel.org/r/20160329175944.33a211cc@kryten
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/genelf.h | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/tools/perf/util/genelf.h b/tools/perf/util/genelf.h
index cd67e64..2fbeb59 100644
--- a/tools/perf/util/genelf.h
+++ b/tools/perf/util/genelf.h
@@ -9,36 +9,32 @@ int jit_add_debug_info(Elf *e, uint64_t code_addr, void 
*debug, int nr_debug_ent
 
 #if   defined(__arm__)
 #define GEN_ELF_ARCH   EM_ARM
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
 #elif defined(__aarch64__)
 #define GEN_ELF_ARCH   EM_AARCH64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__x86_64__)
 #define GEN_ELF_ARCH   EM_X86_64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__i386__)
 #define GEN_ELF_ARCH   EM_386
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
-#elif defined(__ppcle__)
-#define GEN_ELF_ARCH   EM_PPC
-#define GEN_ELF_ENDIAN ELFDATA2LSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpc__)
-#define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2MSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpcle__)
+#elif defined(__powerpc64__)
 #define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
+#elif defined(__powerpc__)
+#define GEN_ELF_ARCH   EM_PPC
+#define GEN_ELF_CLASS  ELFCLASS32
 #else
 #error "unsupported architecture"
 #endif
 
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define GEN_ELF_ENDIAN ELFDATA2MSB
+#else
+#define GEN_ELF_ENDIAN ELFDATA2LSB
+#endif
+
 #if GEN_ELF_CLASS == ELFCLASS64
 #define elf_newehdrelf64_newehdr
 #define elf_getshdrelf64_getshdr

[PATCH] perf jit: genelf makes assumptions about endian

2016-03-29 Thread Anton Blanchard

Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
incorrectly assumed that PowerPC is big endian only.

Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking
for __BYTE_ORDER == __BIG_ENDIAN.

The PowerPC checks were also incorrect, they do not match what gcc
emits. We should first look for __powerpc64__, then __powerpc__.

Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
Signed-off-by: Anton Blanchard <an...@samba.org>
---

diff --git a/tools/perf/util/genelf.h b/tools/perf/util/genelf.h
index cd67e64..2fbeb59 100644
--- a/tools/perf/util/genelf.h
+++ b/tools/perf/util/genelf.h
@@ -9,36 +9,32 @@ int jit_add_debug_info(Elf *e, uint64_t code_addr, void 
*debug, int nr_debug_ent
 
 #if   defined(__arm__)
 #define GEN_ELF_ARCH   EM_ARM
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
 #elif defined(__aarch64__)
 #define GEN_ELF_ARCH   EM_AARCH64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__x86_64__)
 #define GEN_ELF_ARCH   EM_X86_64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__i386__)
 #define GEN_ELF_ARCH   EM_386
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
-#elif defined(__ppcle__)
-#define GEN_ELF_ARCH   EM_PPC
-#define GEN_ELF_ENDIAN ELFDATA2LSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpc__)
-#define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2MSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpcle__)
+#elif defined(__powerpc64__)
 #define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
+#elif defined(__powerpc__)
+#define GEN_ELF_ARCH   EM_PPC
+#define GEN_ELF_CLASS  ELFCLASS32
 #else
 #error "unsupported architecture"
 #endif
 
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define GEN_ELF_ENDIAN ELFDATA2MSB
+#else
+#define GEN_ELF_ENDIAN ELFDATA2LSB
+#endif
+
 #if GEN_ELF_CLASS == ELFCLASS64
 #define elf_newehdrelf64_newehdr
 #define elf_getshdrelf64_getshdr

[PATCH] perf jit: genelf makes assumptions about endian

2016-03-29 Thread Anton Blanchard

Commit 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
incorrectly assumed that PowerPC is big endian only.

Simplify things by consolidating the define of GEN_ELF_ENDIAN and checking
for __BYTE_ORDER == __BIG_ENDIAN.

The PowerPC checks were also incorrect, they do not match what gcc
emits. We should first look for __powerpc64__, then __powerpc__.

Fixes: 9b07e27f88b9 ("perf inject: Add jitdump mmap injection support")
Signed-off-by: Anton Blanchard 
---

diff --git a/tools/perf/util/genelf.h b/tools/perf/util/genelf.h
index cd67e64..2fbeb59 100644
--- a/tools/perf/util/genelf.h
+++ b/tools/perf/util/genelf.h
@@ -9,36 +9,32 @@ int jit_add_debug_info(Elf *e, uint64_t code_addr, void 
*debug, int nr_debug_ent
 
 #if   defined(__arm__)
 #define GEN_ELF_ARCH   EM_ARM
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
 #elif defined(__aarch64__)
 #define GEN_ELF_ARCH   EM_AARCH64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__x86_64__)
 #define GEN_ELF_ARCH   EM_X86_64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
 #elif defined(__i386__)
 #define GEN_ELF_ARCH   EM_386
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS32
-#elif defined(__ppcle__)
-#define GEN_ELF_ARCH   EM_PPC
-#define GEN_ELF_ENDIAN ELFDATA2LSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpc__)
-#define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2MSB
-#define GEN_ELF_CLASS  ELFCLASS64
-#elif defined(__powerpcle__)
+#elif defined(__powerpc64__)
 #define GEN_ELF_ARCH   EM_PPC64
-#define GEN_ELF_ENDIAN ELFDATA2LSB
 #define GEN_ELF_CLASS  ELFCLASS64
+#elif defined(__powerpc__)
+#define GEN_ELF_ARCH   EM_PPC
+#define GEN_ELF_CLASS  ELFCLASS32
 #else
 #error "unsupported architecture"
 #endif
 
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define GEN_ELF_ENDIAN ELFDATA2MSB
+#else
+#define GEN_ELF_ENDIAN ELFDATA2LSB
+#endif
+
 #if GEN_ELF_CLASS == ELFCLASS64
 #define elf_newehdrelf64_newehdr
 #define elf_getshdrelf64_getshdr

Re: [PATCH] powerpc: fix dedotify for binutils >= 2.26

2016-02-06 Thread Anton Blanchard


> Since binutils 2.26 BFD is doing suffix merging on STRTAB sections.
> But dedotify modifies the symbol names in place, which can also modify
> unrelated symbols with a name that matches a suffix of a dotted
> name.  To remove the leading dot of a symbol name we can just
> increment the pointer into the STRTAB section instead.

Thanks Andreas.

> Signed-off-by: Andreas Schwab 

I think we should get it into stable too.

Anton

> ---
>  arch/powerpc/kernel/module_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/module_64.c
> b/arch/powerpc/kernel/module_64.c index ac64ffd..08b7a40 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -340,7 +340,7 @@ static void dedotify(Elf64_Sym *syms, unsigned
> int numsyms, char *strtab) if (name[0] == '.') {
>   if (strcmp(name+1, "TOC.") == 0)
>   syms[i].st_shndx = SHN_ABS;
> - memmove(name, name+1, strlen(name));
> + syms[i].st_name++;
>   }
>   }
>   }

Re: [PATCH] powerpc: fix dedotify for binutils >= 2.26

2016-02-06 Thread Anton Blanchard


> Since binutils 2.26 BFD is doing suffix merging on STRTAB sections.
> But dedotify modifies the symbol names in place, which can also modify
> unrelated symbols with a name that matches a suffix of a dotted
> name.  To remove the leading dot of a symbol name we can just
> increment the pointer into the STRTAB section instead.

Thanks Andreas.

> Signed-off-by: Andreas Schwab 

I think we should get it into stable too.

Anton

> ---
>  arch/powerpc/kernel/module_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/module_64.c
> b/arch/powerpc/kernel/module_64.c index ac64ffd..08b7a40 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -340,7 +340,7 @@ static void dedotify(Elf64_Sym *syms, unsigned
> int numsyms, char *strtab) if (name[0] == '.') {
>   if (strcmp(name+1, "TOC.") == 0)
>   syms[i].st_shndx = SHN_ABS;
> - memmove(name, name+1, strlen(name));
> + syms[i].st_name++;
>   }
>   }
>   }

Re: [PATCH 3/9] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

2015-10-28 Thread Anton Blanchard

Hi Scott,

> I wonder why it was 64-bit specific in the first place.

I think it was part of a series where I added my 64bit assembly checksum
routines, and I didn't step back and think that the wrapper code would
be useful on 32 bit.

Anton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/9] powerpc32: checksum_wrappers_64 becomes checksum_wrappers

2015-10-28 Thread Anton Blanchard

Hi Scott,

> I wonder why it was 64-bit specific in the first place.

I think it was part of a series where I added my 64bit assembly checksum
routines, and I didn't step back and think that the wrapper code would
be useful on 32 bit.

Anton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] Makefile: Fix detection of clang when cross-compiling

2015-07-13 Thread Anton Blanchard

Hi,

>  > When the host's C compiler is clang, and when attempting to
>  > cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the
>  > Makefile would incorrectly detect the use of clang, which
>  > resulted in clang-specific flags being passed to
>  > mipsel-linux-gcc.
>  >
>  > This can be verified under Debian by installing the "clang"
>  > package, and then using it as the default compiler with:
>  > sudo update-alternatives --config cc
>  >
>  > This patch moves the detection of clang after the $(CC)
>  > variable is initialized to the name of the cross-compiler, so
>  > that the check applies
>  > to the cross-compiler and not the host's C compiler.
>  >
>  > v2: Move the detection of clang after the inclusion of the
>  > arch/*/Makefile (as they might set $(CROSS_COMPILE))
>  >
>  > Signed-off-by: Paul Cercueil  >
> 
> Applied to kbuild.git#kbuild. I will push it after v4.1-rc1
> becomes available, though.
> 
> Drat. I wish I saw this earlier.
> 
> This breaks patches which check for the value of COMPILER in 
> arch/*/Makefile. This detection must be performed before the
> inclusion of the arch Makefile.
> 
> Can I move this to after the initialization of CC but before the
> include?
> 
> I'm not sure that being able to define the default compiler per arch
> is necessary. But I know I need to be able to add arch specific flags
> for clang.

I can confirm the patch breaks ppc64le clang builds.

Anton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] Makefile: Fix detection of clang when cross-compiling

2015-07-13 Thread Anton Blanchard

Hi,

   When the host's C compiler is clang, and when attempting to
   cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the
   Makefile would incorrectly detect the use of clang, which
   resulted in clang-specific flags being passed to
   mipsel-linux-gcc.
  
   This can be verified under Debian by installing the clang
   package, and then using it as the default compiler with:
   sudo update-alternatives --config cc
  
   This patch moves the detection of clang after the $(CC)
   variable is initialized to the name of the cross-compiler, so
   that the check applies
   to the cross-compiler and not the host's C compiler.
  
   v2: Move the detection of clang after the inclusion of the
   arch/*/Makefile (as they might set $(CROSS_COMPILE))
  
   Signed-off-by: Paul Cercueil p...@crapouillou.net
 mailto:p...@crapouillou.net
 
 Applied to kbuild.git#kbuild. I will push it after v4.1-rc1
 becomes available, though.
 
 Drat. I wish I saw this earlier.
 
 This breaks patches which check for the value of COMPILER in 
 arch/*/Makefile. This detection must be performed before the
 inclusion of the arch Makefile.
 
 Can I move this to after the initialization of CC but before the
 include?
 
 I'm not sure that being able to define the default compiler per arch
 is necessary. But I know I need to be able to add arch specific flags
 for clang.

I can confirm the patch breaks ppc64le clang builds.

Anton
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

1 2 3 4 5 6 >

1 - 100 of 555 matches

Mail list logo