Re: [PATCH 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel

Nicholas Piggin wrote: Naveen N. Rao's on June 19, 2019 7:53 pm: Nicholas Piggin wrote: Michael Ellerman's on June 19, 2019 3:14 pm: I'm also not convinced the ordering between the two patches is guaranteed by the ISA, given that there's possibly no isync on the other CPU. Will they go

Re: [PATCH 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel

Nicholas Piggin wrote: Michael Ellerman's on June 19, 2019 3:14 pm: Hi Naveen, Sorry I meant to reply to this earlier .. :/ No problem. Thanks for the questions. "Naveen N. Rao" writes: With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to enable functi

Re: [PATCH 5/7] powerpc/ftrace: Update ftrace_location() for powerpc -mprofile-kernel

Steven Rostedt wrote: On Tue, 18 Jun 2019 23:53:11 +0530 "Naveen N. Rao" wrote: Naveen N. Rao wrote: > Steven Rostedt wrote: >> On Tue, 18 Jun 2019 20:17:04 +0530 >> "Naveen N. Rao" wrote: >> >>> @@ -1551,7 +1551,7 @@ unsigned long f

Re: [PATCH 5/7] powerpc/ftrace: Update ftrace_location() for powerpc -mprofile-kernel

Naveen N. Rao wrote: Steven Rostedt wrote: On Tue, 18 Jun 2019 20:17:04 +0530 "Naveen N. Rao" wrote: @@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) key.flags = end;/* overload flags, as it is unsigned long */

Re: [PATCH 5/7] powerpc/ftrace: Update ftrace_location() for powerpc -mprofile-kernel

Steven Rostedt wrote: On Tue, 18 Jun 2019 20:17:04 +0530 "Naveen N. Rao" wrote: @@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) key.flags = end;/* overload flags, as it is unsigned long */ for (pg = ftrace_pages

[PATCH 5/7] powerpc/ftrace: Update ftrace_location() for powerpc -mprofile-kernel

a custom version of ftrace_cmp_recs() which looks at the instruction preceding the branch to _mcount() and marks that instruction as belonging to ftrace if it is a 'nop' or 'mflr r0'. Signed-off-by: Naveen N. Rao --- arch/powerpc/kernel/trace/ftrace.c | 31 ++ include

[PATCH 6/7] kprobes/ftrace: Use ftrace_location() when [dis]arming probes

up ftrace filter IP. This won't work if the address points to any instruction apart from the one that has a branch to _mcount(). To resolve this, have [dis]arm_kprobe_ftrace() use ftrace_function() to identify the filter IP. Signed-off-by: Naveen N. Rao --- kernel/kprobes.c | 10 +- 1 file

[PATCH 0/7] powerpc/ftrace: Patch out -mprofile-kernel instructions

in two instructions being emitted: 'mflr r0' and 'bl _mcount'. So far, we were only nop'ing out the branch to _mcount(). This series implements an approach to also nop out the preceding mflr. - Naveen Naveen N. Rao (7): ftrace: Expose flags used for ftrace_replace_code() x86/ftrace: Fix

[PATCH 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel

ftrace_replace_code() with a powerpc64 variant for this purpose. Suggested-by: Nicholas Piggin Reviewed-by: Nicholas Piggin Signed-off-by: Naveen N. Rao --- arch/powerpc/kernel/trace/ftrace.c | 241 ++--- 1 file changed, 219 insertions(+), 22 deletions(-) diff --git a/arch/powerpc

[PATCH 7/7] powerpc/kprobes: Allow probing on any ftrace address

to the pre and post probe handlers. Signed-off-by: Naveen N. Rao --- arch/powerpc/kernel/kprobes-ftrace.c | 30 1 file changed, 30 insertions(+) diff --git a/arch/powerpc/kernel/kprobes-ftrace.c b/arch/powerpc/kernel/kprobes-ftrace.c index 972cb28174b2..6a0bd3c16cb6

[PATCH 3/7] ftrace: Expose __ftrace_replace_code()

While over-riding ftrace_replace_code(), we still want to reuse the existing __ftrace_replace_code() function. Rename the function and make it available for other kernel code. Signed-off-by: Naveen N. Rao --- include/linux/ftrace.h | 1 + kernel/trace/ftrace.c | 8 2 files changed, 5

[PATCH 1/7] ftrace: Expose flags used for ftrace_replace_code()

Since ftrace_replace_code() is a __weak function and can be overridden, we need to expose the flags that can be set. So, move the flags enum to the header file. Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Naveen N. Rao --- include/linux/ftrace.h | 5 + kernel/trace/ftrace.c | 5

[PATCH 2/7] x86/ftrace: Fix use of flags in ftrace_replace_code()

7fb3c ("ftrace: Allow ftrace_replace_code() to be schedulable") Signed-off-by: Naveen N. Rao --- arch/x86/kernel/ftrace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 0927bb158ffc..f34005a17051 100644 --- a/

Re: [PATCH] Powerpc/Watchpoint: Restore nvgprs while returning from exception

uot;powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors") Reviewed-by: Naveen N. Rao - Naveen

Re: [RFC PATCH 2/4] x86/ftrace: Fix use of flags in ftrace_replace_code()

Hi Steven, Steven Rostedt wrote: On Mon, 20 May 2019 09:13:20 -0400 Steven Rostedt wrote: > I haven't yet tested this patch on x86, but this looked wrong so sending > this as a RFC. This code has been through a bit of updates, and I need to go through and clean it up. I'll have to take

Re: [RFC PATCH 4/4] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel

ction, use synchronize_rcu_tasks() to ensure all existing threads make progress, and then patch in the branch to _mcount(). We override ftrace_replace_code() with a powerpc64 variant for this purpose. Signed-off-by: Nicholas Piggin Signed-off-by: Naveen N. Rao Nice! Thanks for doing a real patch. You need

[RFC PATCH 4/4] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel

e progress, and then patch in the branch to _mcount(). We override ftrace_replace_code() with a powerpc64 variant for this purpose. Signed-off-by: Nicholas Piggin Signed-off-by: Naveen N. Rao --- arch/powerpc/kernel/trace/ftrace.c | 188 + 1 file changed, 166 insertions(+), 22

[RFC PATCH 1/4] ftrace: Expose flags used for ftrace_replace_code()

Since ftrace_replace_code() is a __weak function and can be overridden, we need to expose the flags that can be set. So, move the flags enum to the header file. Signed-off-by: Naveen N. Rao --- include/linux/ftrace.h | 5 + kernel/trace/ftrace.c | 5 - 2 files changed, 5 insertions

[RFC PATCH 2/4] x86/ftrace: Fix use of flags in ftrace_replace_code()

7fb3c ("ftrace: Allow ftrace_replace_code() to be schedulable") Signed-off-by: Naveen N. Rao --- I haven't yet tested this patch on x86, but this looked wrong so sending this as a RFC. - Naveen arch/x86/kernel/ftrace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -

[RFC PATCH 0/4] Nop out the preceding mflr with -mprofile-kernel

, but has not been tested. Patch 4 implements the changes for powerpc64. - Naveen Naveen N. Rao (4): ftrace: Expose flags used for ftrace_replace_code() x86/ftrace: Fix use of flags in ftrace_replace_code() ftrace: Expose __ftrace_replace_code() powerpc/ftrace: Additionally nop out

[RFC PATCH 3/4] ftrace: Expose __ftrace_replace_code()

While over-riding ftrace_replace_code(), we still want to reuse the existing __ftrace_replace_code() function. Rename the function and make it available for other kernel code. Signed-off-by: Naveen N. Rao --- include/linux/ftrace.h | 1 + kernel/trace/ftrace.c | 8 2 files changed, 5

Re: [PATCH] kprobes: fix compilation when KPROBE_EVENTS is enabled without kretpobes

to `kprobe_on_func_entry' make: *** [Makefile:1029: vmlinux] Error 1 Given the fact that these functions have no dependencies on kretprobes i think they should be moved out of the #ifdef CONFIG_KRETPROBES block. Signed-off-by: Sven Schnelle Cc: "Naveen N. Rao" Cc: Anil S Keshavamurthy Cc

Re: [PATCH] perf probe powerpc: Ignore SyS symbols irrespective of endianness

Sandipan Das wrote: This makes sure that the SyS symbols are ignored for any powerpc system, not just the big endian ones. Fixes: fb6d59423115 ("perf probe ppc: Use the right prefix when ignoring SyS symbols on ppc") Reported-by: Naveen N. Rao Signed-off-by: Sandipan Das

Re: [PATCH] perf probe powerpc: Ignore SyS symbols irrespective of endianness

Sandipan Das wrote: This makes sure that the SyS symbols are ignored for any powerpc system, not just the big endian ones. Fixes: fb6d59423115 ("perf probe ppc: Use the right prefix when ignoring SyS symbols on ppc") Reported-by: Naveen N. Rao Signed-off-by: Sandipan Das

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

Song Liu wrote: I am testing the patch set with the following code: #include #include volatile short semaphore = 0; int for_uprobe(int c) { printf("%d\n", c + 10); return c + 1; } int main(int argc, char *argv[]) { for_uprobe(argc); while (1) {

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

Song Liu wrote: I am testing the patch set with the following code: #include #include volatile short semaphore = 0; int for_uprobe(int c) { printf("%d\n", c + 10); return c + 1; } int main(int argc, char *argv[]) { for_uprobe(argc); while (1) {

Re: [PATCH] perf probe powerpc: Fix trace event post-processing

... Fixes: 99e608b5954c ("perf probe ppc64le: Fix probe location when using DWARF") Reported-by: Aneesh Kumar K.V Signed-off-by: Sandipan Das Acked-by: Naveen N. Rao - Naveen

Re: [PATCH] perf probe powerpc: Fix trace event post-processing

... Fixes: 99e608b5954c ("perf probe ppc64le: Fix probe location when using DWARF") Reported-by: Aneesh Kumar K.V Signed-off-by: Sandipan Das Acked-by: Naveen N. Rao - Naveen

Re: [PATCH 4.16 188/279] powerpc/trace/syscalls: Update syscall name matching logic

Greg Kroah-Hartman wrote: 4.16-stable review patch. If anyone has any objections, please let me know. Please drop this and the next patch since these depend on commit e145242ea0df6, which is not in v4.16. - Naveen -- From: "Naveen N. Rao" [ Upstr

Re: [PATCH 4.16 188/279] powerpc/trace/syscalls: Update syscall name matching logic

Greg Kroah-Hartman wrote: 4.16-stable review patch. If anyone has any objections, please let me know. Please drop this and the next patch since these depend on commit e145242ea0df6, which is not in v4.16. - Naveen -- From: "Naveen N. Rao" [ Upstr

Re: [PATCH 4.14 120/189] powerpc/trace/syscalls: Update syscall name matching logic

Greg Kroah-Hartman wrote: 4.14-stable review patch. If anyone has any objections, please let me know. Please drop this and the next patch since these depend on commit e145242ea0df6, which is not in v4.14. - Naveen -- From: "Naveen N. Rao" [ Upstr

Re: [PATCH 4.14 120/189] powerpc/trace/syscalls: Update syscall name matching logic

Greg Kroah-Hartman wrote: 4.14-stable review patch. If anyone has any objections, please let me know. Please drop this and the next patch since these depend on commit e145242ea0df6, which is not in v4.14. - Naveen -- From: "Naveen N. Rao" [ Upstr

Re: [PATCH 2/2] powerpc: Add support for function error injection

Naveen N. Rao wrote: Michael Ellerman wrote: I guess if it doesn't already apply to tip you should rebase it. You've probably missed 4.18 anyway. Oh ok. I just tried and it seems to apply just fine. I'll post v2 after giving this a quick test. I didn't post a v2 since I have decided

Re: [PATCH 2/2] powerpc: Add support for function error injection

Naveen N. Rao wrote: Michael Ellerman wrote: I guess if it doesn't already apply to tip you should rebase it. You've probably missed 4.18 anyway. Oh ok. I just tried and it seems to apply just fine. I'll post v2 after giving this a quick test. I didn't post a v2 since I have decided

[PATCH] selftests/ftrace: Add ppc support for kprobe args tests

Add powerpc support for the recently added kprobe args tests. Signed-off-by: Naveen N. Rao --- .../selftests/ftrace/test.d/kprobe/kprobe_args_string.tc | 8 .../selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc | 7 +++ 2 files changed, 15 insertions(+) diff --git a/tools

[PATCH] selftests/ftrace: Add ppc support for kprobe args tests

Add powerpc support for the recently added kprobe args tests. Signed-off-by: Naveen N. Rao --- .../selftests/ftrace/test.d/kprobe/kprobe_args_string.tc | 8 .../selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc | 7 +++ 2 files changed, 15 insertions(+) diff --git a/tools

Re: [PATCH -tip v4 24/27] bpf: error-inject: kprobes: Clear current_kprobe and enable preempt in kprobe

Masami Hiramatsu wrote: On Thu, 31 May 2018 16:25:38 +0530 "Naveen N. Rao" wrote: Masami Hiramatsu wrote: > Clear current_kprobe and enable preemption in kprobe > even if pre_handler returns !0. > > This simplifies function override using kprobes. > > Jp

Re: [PATCH -tip v4 24/27] bpf: error-inject: kprobes: Clear current_kprobe and enable preempt in kprobe

Masami Hiramatsu wrote: On Thu, 31 May 2018 16:25:38 +0530 "Naveen N. Rao" wrote: Masami Hiramatsu wrote: > Clear current_kprobe and enable preemption in kprobe > even if pre_handler returns !0. > > This simplifies function override using kprobes. > > Jp

Re: [PATCH -tip v4 24/27] bpf: error-inject: kprobes: Clear current_kprobe and enable preempt in kprobe

Masami Hiramatsu wrote: Clear current_kprobe and enable preemption in kprobe even if pre_handler returns !0. This simplifies function override using kprobes. Jprobe used to require to keep the preemption disabled and keep current_kprobe until it returned to original function entry. For this

Re: [PATCH -tip v4 24/27] bpf: error-inject: kprobes: Clear current_kprobe and enable preempt in kprobe

Masami Hiramatsu wrote: Clear current_kprobe and enable preemption in kprobe even if pre_handler returns !0. This simplifies function override using kprobes. Jprobe used to require to keep the preemption disabled and keep current_kprobe until it returned to original function entry. For this

Re: [PATCH -tip v4 00/27] kprobes: Cleanup jprobe implementation

Hi Masami, Masami Hiramatsu wrote: Hi Naveen, Sorry, I might miss to add you on CC list. Could you test and review this on powerpc? Sure, thanks for letting me know. If possible, please mark powerpc patches to linuxppc-...@lists.ozlabs.org so that it gets good review. - Naveen

Re: [PATCH -tip v4 00/27] kprobes: Cleanup jprobe implementation

Hi Masami, Masami Hiramatsu wrote: Hi Naveen, Sorry, I might miss to add you on CC list. Could you test and review this on powerpc? Sure, thanks for letting me know. If possible, please mark powerpc patches to linuxppc-...@lists.ozlabs.org so that it gets good review. - Naveen

[PATCH 2/2] powerpc: Add support for function error injection

Signed-off-by: Naveen N. Rao --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/error-injection.h | 9 + arch/powerpc/include/asm/ptrace.h | 5 + 3 files changed, 15 insertions(+) create mode 100644 arch/powerpc/include/asm/error-injection.h

[PATCH 2/2] powerpc: Add support for function error injection

Signed-off-by: Naveen N. Rao --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/error-injection.h | 9 + arch/powerpc/include/asm/ptrace.h | 5 + 3 files changed, 15 insertions(+) create mode 100644 arch/powerpc/include/asm/error-injection.h

Re: [RFC] powerpc/emulate_step: Fix kernel crash when VSX is not present

[Adding Mikey] Ravi Bangoria wrote: emulate_step() is not checking runtime VSX feature flag before emulating an instruction. This can cause kernel oops when kernel is compiled with CONFIG_VSX=y but running on machine where VSX is not supported or disabled. Ex, while running emulate_step tests

Re: [RFC] powerpc/emulate_step: Fix kernel crash when VSX is not present

[Adding Mikey] Ravi Bangoria wrote: emulate_step() is not checking runtime VSX feature flag before emulating an instruction. This can cause kernel oops when kernel is compiled with CONFIG_VSX=y but running on machine where VSX is not supported or disabled. Ex, while running emulate_step tests

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Tue, 08 May 2018 15:41:11 +0530 "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> wrote: Masami Hiramatsu wrote: > On Mon, 07 May 2018 13:41:53 +0530 > "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> wrote: >> >>

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Tue, 08 May 2018 15:41:11 +0530 "Naveen N. Rao" wrote: Masami Hiramatsu wrote: > On Mon, 07 May 2018 13:41:53 +0530 > "Naveen N. Rao" wrote: >> >> >> >> I didn't understand that. Which code are you planning to rem

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Mon, 07 May 2018 13:41:53 +0530 "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> wrote: >> >> I didn't understand that. Which code are you planning to remove? Can you >> please elaborate? I thought we still need to disable pr

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Mon, 07 May 2018 13:41:53 +0530 "Naveen N. Rao" wrote: >> >> I didn't understand that. Which code are you planning to remove? Can you >> please elaborate? I thought we still need to disable preemption in the >> ftrace handler. >

Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)

Masami Hiramatsu wrote: On Mon, 7 May 2018 13:51:21 +0530 Ravi Bangoria wrote: BTW, same issue exists for normal uprobe. If uprobe_mmap() fails, there is no feedback to trace_uprobe and no warnigns in dmesg as well !! There was a patch by Naveen to warn such

Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)

Masami Hiramatsu wrote: On Mon, 7 May 2018 13:51:21 +0530 Ravi Bangoria wrote: BTW, same issue exists for normal uprobe. If uprobe_mmap() fails, there is no feedback to trace_uprobe and no warnigns in dmesg as well !! There was a patch by Naveen to warn such failures in dmesg but that didn't

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Sat, 05 May 2018 13:16:04 +0530 "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> wrote: Masami Hiramatsu wrote: > On Fri, 4 May 2018 12:06:42 -0400 > Steven Rostedt <rost...@goodmis.org> wrote: > >> On Sat, 5 May 2018 00:48

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Sat, 05 May 2018 13:16:04 +0530 "Naveen N. Rao" wrote: Masami Hiramatsu wrote: > On Fri, 4 May 2018 12:06:42 -0400 > Steven Rostedt wrote: > >> On Sat, 5 May 2018 00:48:28 +0900 >> Masami Hiramatsu wrote: >> >> &

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Fri, 4 May 2018 12:06:42 -0400 Steven Rostedt wrote: On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > > Also, when looking at the kprobe code, I was looking at this > > function: > > > > > /* Ftrace callback

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Masami Hiramatsu wrote: On Fri, 4 May 2018 12:06:42 -0400 Steven Rostedt wrote: On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > > Also, when looking at the kprobe code, I was looking at this > > function: > > > > > /* Ftrace callback handler for kprobes -- called under

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Steven Rostedt wrote: On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > > Also, when looking at the kprobe code, I was looking at this function: > > > /* Ftrace callback handler for kprobes -- called under preepmt disabed */ > > void

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Steven Rostedt wrote: On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > > Also, when looking at the kprobe code, I was looking at this function: > > > /* Ftrace callback handler for kprobes -- called under preepmt disabed */ > > void kprobe_ftrace_handler(unsigned long ip,

Re: [PATCH 1/6] powerpc/syscalls: Switch trivial cases to SYSCALL_DEFINE

Michael Ellerman wrote: From: Al Viro Signed-off-by: Al Viro --- arch/powerpc/kernel/pci_32.c | 6 +++--- arch/powerpc/kernel/pci_64.c | 4 ++-- arch/powerpc/mm/subpage-prot.c | 4 +++-

Re: [PATCH 1/6] powerpc/syscalls: Switch trivial cases to SYSCALL_DEFINE

Michael Ellerman wrote: From: Al Viro Signed-off-by: Al Viro --- arch/powerpc/kernel/pci_32.c | 6 +++--- arch/powerpc/kernel/pci_64.c | 4 ++-- arch/powerpc/mm/subpage-prot.c | 4 +++- arch/powerpc/platforms/cell/spu_syscalls.c | 3 ++- 4 files

Re: [PATCH AUTOSEL for 4.9 005/219] kretprobes: Ensure probe location is at function entry

Hi Sasha, Sasha Levin wrote: From: "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> [ Upstream commit 90ec5e89e393c76e19afc845d8f88a5dc8315919 ] Sorry if this is obvious, but why was this patch picked up for -stable? I don't see the upstream commit tagging -stable

Re: [PATCH AUTOSEL for 4.9 005/219] kretprobes: Ensure probe location is at function entry

Hi Sasha, Sasha Levin wrote: From: "Naveen N. Rao" [ Upstream commit 90ec5e89e393c76e19afc845d8f88a5dc8315919 ] Sorry if this is obvious, but why was this patch picked up for -stable? I don't see the upstream commit tagging -stable, so curious why this was done. I d

Re: [PATCH 9/9] perf tests: Use arch__compare_symbol_names to compare symbols

mbols automatically") And CCed Naveen, the author of that patch, so that gets notified of this fix. Thanks! This does fix the test on ppc64 BE. So: Acked-and-Tested-by: Naveen N. Rao <naveen.n@linux.vnet.ibm.com> - Naveen

Re: [PATCH 9/9] perf tests: Use arch__compare_symbol_names to compare symbols

mbols automatically") And CCed Naveen, the author of that patch, so that gets notified of this fix. Thanks! This does fix the test on ppc64 BE. So: Acked-and-Tested-by: Naveen N. Rao - Naveen

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

] perf_event_interrupt+0x298/0x460 [c0027964] performance_monitor_exception+0x54/0x70 [c0009ba4] performance_monitor_common+0x114/0x120 Fix this by deferefencing them safely. Suggested-by: Naveen N. Rao <naveen.n@linux.vnet.ibm.com> Signed-off-by: Ravi Bangoria <r

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

] perf_event_interrupt+0x298/0x460 [c0027964] performance_monitor_exception+0x54/0x70 [c0009ba4] performance_monitor_common+0x114/0x120 Fix this by deferefencing them safely. Suggested-by: Naveen N. Rao Signed-off-by: Ravi Bangoria Reviewed-by: Naveen N. Rao - Naveen

Re: [PATCH v4 1/1] perf/bench/numa: Fixup discontiguous/sparse numa nodes

taking nodes that are exposed by kernel to userspace. Cc: Arnaldo Carvalho de Melo <a...@kernel.org> Cc: Naveen N. Rao <naveen.n@linux.vnet.ibm.com> Reviewed-by: Srikar Dronamraju <sri...@linux.vnet.ibm.com> Signed-off-by: Satheesh Rajendran <sathn...@linux.vnet.ibm.com> Sig

Re: [PATCH v4 1/1] perf/bench/numa: Fixup discontiguous/sparse numa nodes

to userspace. Cc: Arnaldo Carvalho de Melo Cc: Naveen N. Rao Reviewed-by: Srikar Dronamraju Signed-off-by: Satheesh Rajendran Signed-off-by: Balamuruhan S --- tools/perf/bench/numa.c | 57 +++-- 1 file changed, 51 insertions(+), 6 deletions(-) diff

Re: [PATCH v4.2] powerpc/modules: Don't try to restore r2 after a sibling call

Kamalesh Babulal wrote: On Thursday 16 November 2017 11:15 PM, Josh Poimboeuf wrote: On Thu, Nov 16, 2017 at 06:39:03PM +0530, Naveen N. Rao wrote: Josh Poimboeuf wrote: On Wed, Nov 15, 2017 at 02:58:33PM +0530, Naveen N. Rao wrote: +int instr_is_link_branch(unsigned int instr

Re: [PATCH v4.2] powerpc/modules: Don't try to restore r2 after a sibling call

Kamalesh Babulal wrote: On Thursday 16 November 2017 11:15 PM, Josh Poimboeuf wrote: On Thu, Nov 16, 2017 at 06:39:03PM +0530, Naveen N. Rao wrote: Josh Poimboeuf wrote: On Wed, Nov 15, 2017 at 02:58:33PM +0530, Naveen N. Rao wrote: +int instr_is_link_branch(unsigned int instr

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

Josh Poimboeuf wrote: On Wed, Nov 15, 2017 at 02:58:33PM +0530, Naveen N. Rao wrote: > +int instr_is_link_branch(unsigned int instr) > +{ > + return (instr_is_branch_iform(instr) || instr_is_branch_bform(instr)) && > + (instr & BRANCH_SET_LINK); > +} >

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

Josh Poimboeuf wrote: On Wed, Nov 15, 2017 at 02:58:33PM +0530, Naveen N. Rao wrote: > +int instr_is_link_branch(unsigned int instr) > +{ > + return (instr_is_branch_iform(instr) || instr_is_branch_bform(instr)) && > + (instr & BRANCH_SET_LINK); > +} >

Re: [PATCH v3 2/2] perf/bench/numa: Handle discontiguous/sparse numa nodes

Hi Satheesh, Satheesh Rajendran wrote: Hi Naveen, On Tue, 2017-10-31 at 20:46 +0530, Naveen N. Rao wrote:   >   } >   BUG_ON(nr_min > nr_max); > - Looks like an un-necessary change there. - Naveen I had hit with this compilation error, so had to move the initializatio

Re: [PATCH v3 2/2] perf/bench/numa: Handle discontiguous/sparse numa nodes

Hi Satheesh, Satheesh Rajendran wrote: Hi Naveen, On Tue, 2017-10-31 at 20:46 +0530, Naveen N. Rao wrote:   >   } >   BUG_ON(nr_min > nr_max); > - Looks like an un-necessary change there. - Naveen I had hit with this compilation error, so had to move the initializatio

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

Josh Poimboeuf wrote: On Tue, Nov 14, 2017 at 03:59:21PM +0530, Naveen N. Rao wrote: Kamalesh Babulal wrote: > From: Josh Poimboeuf <jpoim...@redhat.com> > > When attempting to load a livepatch module, I got the following error: > > module_64: patch_module: Expect noo

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

Josh Poimboeuf wrote: On Tue, Nov 14, 2017 at 03:59:21PM +0530, Naveen N. Rao wrote: Kamalesh Babulal wrote: > From: Josh Poimboeuf > > When attempting to load a livepatch module, I got the following error: > > module_64: patch_module: Expect noop after relocat

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

Kamalesh Babulal wrote: From: Josh Poimboeuf When attempting to load a livepatch module, I got the following error: module_64: patch_module: Expect noop after relocate, got 3c82 The error was triggered by the following code in unregister_netdevice_queue(): 14c:

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

Kamalesh Babulal wrote: From: Josh Poimboeuf When attempting to load a livepatch module, I got the following error: module_64: patch_module: Expect noop after relocate, got 3c82 The error was triggered by the following code in unregister_netdevice_queue(): 14c: 00 00 00 48 b

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Alexei Starovoitov wrote: On 11/7/17 12:55 AM, Naveen N. Rao wrote: I thought such struct shouldn't change layout. If it is we need to fix include/linux/compiler-clang.h to do that anon struct as well. We considered that, but it looked to be very dependent on the version of gcc used to build

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Alexei Starovoitov wrote: On 11/7/17 12:55 AM, Naveen N. Rao wrote: I thought such struct shouldn't change layout. If it is we need to fix include/linux/compiler-clang.h to do that anon struct as well. We considered that, but it looked to be very dependent on the version of gcc used to build

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Alexei Starovoitov wrote: On 11/5/17 2:31 AM, Naveen N. Rao wrote: Hi Alexei, Alexei Starovoitov wrote: On 11/3/17 3:58 PM, Sandipan Das wrote: For added security, the layout of some structures can be randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One such structure is task_struct

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Alexei Starovoitov wrote: On 11/5/17 2:31 AM, Naveen N. Rao wrote: Hi Alexei, Alexei Starovoitov wrote: On 11/3/17 3:58 PM, Sandipan Das wrote: For added security, the layout of some structures can be randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One such structure is task_struct

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Hi Alexei, Alexei Starovoitov wrote: On 11/3/17 3:58 PM, Sandipan Das wrote: For added security, the layout of some structures can be randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One such structure is task_struct. To build BPF programs, we use Clang which does not support this feature.

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Hi Alexei, Alexei Starovoitov wrote: On 11/3/17 3:58 PM, Sandipan Das wrote: For added security, the layout of some structures can be randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One such structure is task_struct. To build BPF programs, we use Clang which does not support this feature.

Re: [PATCH v3 2/2] perf/bench/numa: Handle discontiguous/sparse numa nodes

On 2017/08/21 10:17AM, sathn...@linux.vnet.ibm.com wrote: > From: Satheesh Rajendran > > Certain systems are designed to have sparse/discontiguous nodes. > On such systems, perf bench numa hangs, shows wrong number of nodes > and shows values for non-existent nodes.

Re: [PATCH v3 2/2] perf/bench/numa: Handle discontiguous/sparse numa nodes

On 2017/08/21 10:17AM, sathn...@linux.vnet.ibm.com wrote: > From: Satheesh Rajendran > > Certain systems are designed to have sparse/discontiguous nodes. > On such systems, perf bench numa hangs, shows wrong number of nodes > and shows values for non-existent nodes. Handle this by only > taking

Re: [PATCH v3 1/2] perf/bench/numa: Add functions to detect sparse numa nodes

Hi Satheesh, On 2017/08/21 10:15AM, sathn...@linux.vnet.ibm.com wrote: > From: Satheesh Rajendran > > Added functions 1) to get a count of all nodes that are exposed to > userspace. These nodes could be memoryless cpu nodes or cpuless memory > nodes, 2) to check

Re: [PATCH v3 1/2] perf/bench/numa: Add functions to detect sparse numa nodes

Hi Satheesh, On 2017/08/21 10:15AM, sathn...@linux.vnet.ibm.com wrote: > From: Satheesh Rajendran > > Added functions 1) to get a count of all nodes that are exposed to > userspace. These nodes could be memoryless cpu nodes or cpuless memory > nodes, 2) to check given node is present and 3) to

Re: [RFC] perf tool: Fix memory corruption because of zero length symbols

On 2017/10/25 08:28AM, Jiri Olsa wrote: > On Tue, Oct 24, 2017 at 07:50:06PM +0530, Ravi Bangoria wrote: > > Perf top is often crashing at very random locations on powerpc. > > After investigating, I found the crash only happens when sample > > is of zero length symbol. Powerpc kernel has many

Re: [RFC] perf tool: Fix memory corruption because of zero length symbols

On 2017/10/25 08:28AM, Jiri Olsa wrote: > On Tue, Oct 24, 2017 at 07:50:06PM +0530, Ravi Bangoria wrote: > > Perf top is often crashing at very random locations on powerpc. > > After investigating, I found the crash only happens when sample > > is of zero length symbol. Powerpc kernel has many

Re: [PATCH] Revert "kprobes: Warn if optprobe handler tries to change execution path"

On 2017/10/19 09:38PM, Masami Hiramatsu wrote: > On Tue, 17 Oct 2017 13:48:34 +0530 > "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> wrote: > > > This reverts commit e863d539614641 ("kprobes: Warn if optprobe handler > > tries to change execution pat

Re: [PATCH] Revert "kprobes: Warn if optprobe handler tries to change execution path"

On 2017/10/19 09:38PM, Masami Hiramatsu wrote: > On Tue, 17 Oct 2017 13:48:34 +0530 > "Naveen N. Rao" wrote: > > > This reverts commit e863d539614641 ("kprobes: Warn if optprobe handler > > tries to change execution path"). > > > > On power

[tip:perf/core] Revert "kprobes: Warn if optprobe handler tries to change execution path"

Commit-ID: 4f3a871443669c6b4d458a60ac8d8ca5eedc3f97 Gitweb: https://git.kernel.org/tip/4f3a871443669c6b4d458a60ac8d8ca5eedc3f97 Author: Naveen N. Rao <naveen.n@linux.vnet.ibm.com> AuthorDate: Tue, 17 Oct 2017 13:48:34 +0530 Committer: Ingo Molnar <mi...@kernel.org> Com

[tip:perf/core] Revert "kprobes: Warn if optprobe handler tries to change execution path"

Commit-ID: 4f3a871443669c6b4d458a60ac8d8ca5eedc3f97 Gitweb: https://git.kernel.org/tip/4f3a871443669c6b4d458a60ac8d8ca5eedc3f97 Author: Naveen N. Rao AuthorDate: Tue, 17 Oct 2017 13:48:34 +0530 Committer: Ingo Molnar CommitDate: Wed, 18 Oct 2017 15:21:35 +0200 Revert "kprobes:

[PATCH] Revert "kprobes: Warn if optprobe handler tries to change execution path"

e optprobe as described in commit 762df10bad6954 ("powerpc/kprobes: Optimize kprobe in kretprobe_trampoline()"). With the above commit, we end up with a warning. As such, revert this change. Reported-by: Michael Ellerman <m...@ellerman.id.au> Signed-off-by: Naveen N. Rao <na

[PATCH] Revert "kprobes: Warn if optprobe handler tries to change execution path"

e optprobe as described in commit 762df10bad6954 ("powerpc/kprobes: Optimize kprobe in kretprobe_trampoline()"). With the above commit, we end up with a warning. As such, revert this change. Reported-by: Michael Ellerman Signed-off-by: Naveen N. Rao --- Discussion here: https://www.ma

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

On 2017/10/12 05:04AM, Masami Hiramatsu wrote: > On Tue, 10 Oct 2017 22:32:31 +0530 > "Naveen N. Rao" <naveen.n@linux.vnet.ibm.com> wrote: > > > On 2017/09/19 10:00AM, Masami Hiramatsu wrote: > > So, we don't seem to _require_ users to return !0 if the han

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

On 2017/10/12 05:04AM, Masami Hiramatsu wrote: > On Tue, 10 Oct 2017 22:32:31 +0530 > "Naveen N. Rao" wrote: > > > On 2017/09/19 10:00AM, Masami Hiramatsu wrote: > > So, we don't seem to _require_ users to return !0 if the handler > > changes [n]ip? Or t

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

On 2017/09/19 10:00AM, Masami Hiramatsu wrote: > Warn if optprobe handler tries to change execution path. > As described in Documentation/kprobes.txt, with optprobe > user handler can not change instruction pointer. In that > case user must avoid optimizing the kprobes by setting > post_handler or

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

On 2017/09/19 10:00AM, Masami Hiramatsu wrote: > Warn if optprobe handler tries to change execution path. > As described in Documentation/kprobes.txt, with optprobe > user handler can not change instruction pointer. In that > case user must avoid optimizing the kprobes by setting > post_handler or

<    1   2   3   4   5   6   7   8   9   10   >