Re: lkml delivery: was: Re: [PATCH next v4 00/15] printk: remove logbuf_lock

2021-03-03 Thread Steven Rostedt
On Wed, 3 Mar 2021 14:18:29 +0100 Petr Mladek wrote: > Hi John, > > On Wed 2021-03-03 11:15:13, John Ogness wrote: > > Hello, > > > > Here is v4 of a series to remove @logbuf_lock, exposing the > > ringbuffer locklessly to both readers and writers. v3 is > > here [0]. > > Have you got some

Re: [RFC PATCH 03/14] ftrace: Fix cleanup in error path of register_ftrace_direct()

2020-11-30 Thread Steven Rostedt
On Thu, 26 Nov 2020 23:38:40 +0530 "Naveen N. Rao" wrote: > We need to remove hash entry if register_ftrace_function() fails. > Consolidate the cleanup to be done after register_ftrace_function() at > the end. Reviewed-by: Steven Rostedt (VMware) -- Steve > > Sig

Re: [RFC PATCH 02/14] ftrace: Fix DYNAMIC_FTRACE_WITH_DIRECT_CALLS dependency

2020-11-30 Thread Steven Rostedt
On Thu, 26 Nov 2020 23:38:39 +0530 "Naveen N. Rao" wrote: > DYNAMIC_FTRACE_WITH_DIRECT_CALLS should depend on > DYNAMIC_FTRACE_WITH_REGS since we need ftrace_regs_caller(). > > Fixes: 763e34e74bb7d5c ("ftrace: Add register_ftrace_direct()") > Signed-off-by: Naveen N. Rao I'm pulling this in

Re: [RFC PATCH 01/14] ftrace: Fix updating FTRACE_FL_TRAMP

2020-11-30 Thread Steven Rostedt
On Thu, 26 Nov 2020 23:38:38 +0530 "Naveen N. Rao" wrote: > On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in > ftrace_get_addr_new() followed by the below message: > Bad trampoline accounting at: 4222522f (wake_up_process+0xc/0x20) > (f001) > > The set of steps leading

[for-next][PATCH 11/17] ftrace: Add recording of functions that caused recursion

2020-11-11 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file "recursed_functions" all the functions that caused recursion while a callback to the function tracer was running. Link: https://lkml.kernel.org/r/20201106023548.102375...@goo

[for-next][PATCH 05/17] kprobes/ftrace: Add recursion protection to the ftrace callback

2020-11-11 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" If a ftrace callback does not supply its own recursion protection and does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will make a helper trampoline to do so before calling the callback instead of just calling the callback directly. T

Re: [PATCH 11/11 v3] ftrace: Add recording of functions that caused recursion

2020-11-06 Thread Steven Rostedt
On Fri, 6 Nov 2020 14:13:17 +0100 Petr Mladek wrote: > JFYI, the code reading and writing the cache looks good to me. > > It is still possible that some entries might stay unused (filled > with zeroes) but it should be hard to hit in practice. It > is good enough from my POV. You mean the part

Re: [PATCH 11/11 v2.2] ftrace: Add recording of functions that caused recursion

2020-11-04 Thread Steven Rostedt
raced and detect the recursion and that would call the recording, which (BOOM!) Anyway, I decided to simply use another bit to protect against that. New patch: From a1f2aae996506169f2561986656f898d067d398b Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu,

[PATCH 05/11 v2.1] kprobes/ftrace: Add recursion protection to the ftrace callback

2020-11-04 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" If a ftrace callback does not supply its own recursion protection and does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will make a helper trampoline to do so before calling the callback instead of just calling the callback directly. T

Re: [PATCH 11/11 v2.2] ftrace: Add recording of functions that caused recursion

2020-11-03 Thread Steven Rostedt
On Tue, 3 Nov 2020 15:10:43 +0100 Petr Mladek wrote: > BTW: What is actually the purpose of paranoid_test, please? > > It prevents nested ftrace_record_recursion() calls on the same CPU > (recursion, nesting from IRQ, NMI context). > > Parallel calls from different CPUs are still possible: >

[PATCH 11/11 v2.2] ftrace: Add recording of functions that caused recursion

2020-11-02 Thread Steven Rostedt
From c532ff6b048dd4a12943b05c7b8ce30666c587c8 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu, 29 Oct 2020 15:27:06 -0400 Subject: [PATCH] ftrace: Add recording of functions that caused recursion This adds CONFIG_FTRACE_RECORD_RECURSION that will record

[PATCH 11/11 v2.1] ftrace: Add recording of functions that caused recursion

2020-11-02 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file "recursed_functions" all the functions that caused recursion while a callback to the function tracer was running. Cc: Jonathan Corbet Cc: Guo Ren Cc: "James E.J. Bot

Re: [PATCH 11/11 v2] ftrace: Add recording of functions that caused recursion

2020-11-02 Thread Steven Rostedt
On Mon, 2 Nov 2020 12:37:21 -0500 Steven Rostedt wrote: > The only race that I see that can happen, is the one in the comment I > showed. And that is after enabling the recursed functions again after > clearing, one CPU could add a function while another CPU that just added > that s

Re: [PATCH 11/11 v2] ftrace: Add recording of functions that caused recursion

2020-11-02 Thread Steven Rostedt
On Mon, 2 Nov 2020 17:41:47 +0100 Petr Mladek wrote: > > + i = atomic_read(_records); > > + smp_mb__after_atomic(); > > + if (i < 0) > > + cmpxchg(_functions[index].ip, ip, 0); > > + else if (i <= index) > > + atomic_cmpxchg(_records, i, index + 1); > > This looks

Re: [PATCH 11/11 v2] ftrace: Add recording of functions that caused recursion

2020-11-02 Thread Steven Rostedt
On Mon, 2 Nov 2020 12:09:07 -0500 Steven Rostedt wrote: > > > +void ftrace_record_recursion(unsigned long ip, unsigned long parent_ip) > > > +{ > > > + int index; > > > + int i = 0; > > > + unsigned long old; > > > + > > > + again:

Re: [PATCH 11/11 v2] ftrace: Add recording of functions that caused recursion

2020-11-02 Thread Steven Rostedt
On Mon, 2 Nov 2020 17:41:47 +0100 Petr Mladek wrote: > On Fri 2020-10-30 17:31:53, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file > > "recursed_functions"

[PATCH 05/11 v2] kprobes/ftrace: Add recursion protection to the ftrace callback

2020-10-30 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" If a ftrace callback does not supply its own recursion protection and does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will make a helper trampoline to do so before calling the callback instead of just calling the callback directly. T

[PATCH 11/11 v2] ftrace: Add recording of functions that caused recursion

2020-10-30 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file "recursed_functions" all the functions that caused recursion while a callback to the function tracer was running. Cc: Jonathan Corbet Cc: Guo Ren Cc: "James E.J. Bot

Re: [PATCH 5/9] kprobes/ftrace: Add recursion protection to the ftrace callback

2020-10-29 Thread Steven Rostedt
On Thu, 29 Oct 2020 16:58:03 +0900 Masami Hiramatsu wrote: > Hi Steve, > > On Wed, 28 Oct 2020 07:52:49 -0400 > Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > If a ftrace callback does not supply its own recursion protection a

[PATCH 5/9] kprobes/ftrace: Add recursion protection to the ftrace callback

2020-10-28 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" If a ftrace callback does not supply its own recursion protection and does not set the RECURSION_SAFE flag in its ftrace_ops, then ftrace will make a helper trampoline to do so before calling the callback instead of just calling the callback directly. T

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Steven Rostedt
On Thu, 24 Sep 2020 19:55:10 +0200 Thomas Gleixner wrote: > On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > > On Thu, 24 Sep 2020 08:57:52 +0200 > > Thomas Gleixner wrote: > > > >> > Now as for migration disabled nesting, at least now we would have >

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Steven Rostedt
On Thu, 24 Sep 2020 14:42:41 +0200 Peter Zijlstra wrote: > On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > > Anyway, instead of blocking. What about having a counter of number of > > migrate disabled tasks per cpu, and when taking a migrate_disable(), a

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Steven Rostedt
On Thu, 24 Sep 2020 08:57:52 +0200 Thomas Gleixner wrote: > > Now as for migration disabled nesting, at least now we would have > > groupings of this, and perhaps the theorists can handle that. I mean, > > how is this much different that having a bunch of tasks blocked on a > > mutex with the

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-23 Thread Steven Rostedt
On Wed, 23 Sep 2020 22:55:54 +0200 Thomas Gleixner wrote: > > Perhaps make migrate_disable() an anonymous local_lock()? > > > > This should lower the SHC in theory, if you can't have stacked migrate > > disables on the same CPU. > > I'm pretty sure this ends up in locking hell pretty fast and

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-23 Thread Steven Rostedt
On Wed, 23 Sep 2020 10:40:32 +0200 pet...@infradead.org wrote: > However, with migrate_disable() we can have each task preempted in a > migrate_disable() region, worse we can stack them all on the _same_ CPU > (super ridiculous odds, sure). And then we end up only able to run one > task, with the

Re: [PATCH] recordmcount: Fix build failure on non arm64

2020-08-10 Thread Steven Rostedt
On Mon, 10 Aug 2020 13:18:55 +0100 Catalin Marinas wrote: > > Oops, thanks for fixing this. > > > > Acked-by: Gregory Herrero > > Thanks. I'll queue it via the arm64 tree (as I did with the previous > fix) but I'll wait a bit for Steve to ack it. Acked

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Steven Rostedt
On Tue, 14 Jul 2020 15:56:52 +0200 Jessica Yu wrote: > As Ard and Will have already explained, the major issue I'm having > with this is that we're taking module_alloc(), an allocator that was > originally specific to module loading, and turning it into a generic > interface to be used by other

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Steven Rostedt
On Tue, 14 Jul 2020 14:33:14 +0100 Mark Rutland wrote: > > Should work for all cases. Yes, we might then want something like a per > > arch: > > > > {BPF,FTRACE,KPROBE}_TEXT_TYPE > > ... at that point why not: > > text_alloc_ftrace(); > text_alloc_module(); > text_alloc_bpf(); >

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-13 Thread Steven Rostedt
On Mon, 13 Jul 2020 22:49:48 +0300 Ard Biesheuvel wrote: > On arm64, we no longer use module_alloc for bpf or kprobes, to avoid > wasting va space on code that does not need to be loaded close to the > kernel. Also, module_alloc() allocates kasan shadow, which is > unnecessary for kprobes or bpf

Re: [PATCH] kbuild: introduce ccflags-remove-y and asflags-remove-y

2020-06-28 Thread Steven Rostedt
y to clean up some Makefiles. > > Suggested-by: Sami Tolvanen > Signed-off-by: Masahiro Yamada > --- Nice feature! Acked-by: Steven Rostedt (VMware) -- Steve

Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Steven Rostedt
On Mon, 15 Jun 2020 14:55:52 +0200 Borislav Petkov wrote: > Can you please resend your patchset once a week like everyone else and > not flood inboxes with it? Boris, Haven't you automated your inbox yet? I have patchwork reading my INBOX and it's smart enough to understand new series, and the

Re: [PATCH v8 2/5] seq_buf: Export seq_buf_printf

2020-06-01 Thread Steven Rostedt
ars it was a reply to a private email you sent to me. I didn't realize it was off list. Anyway: Acked-by: Steven Rostedt (VMware) -- Steve

Re: [PATCH v7 2/5] seq_buf: Export seq_buf_printf() to external modules

2020-05-08 Thread Steven Rostedt
On Fri, 8 May 2020 18:09:35 +0200 Borislav Petkov wrote: > On Fri, May 08, 2020 at 05:30:31PM +0530, Vaibhav Jain wrote: > > I am referring to Kernel Loadable Modules with MODULE_LICENSE("GPL") > > here. > > And what does "external" refer to? Because if it is out-of-tree, we > don't export

Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()

2020-04-25 Thread Steven Rostedt
On Sat, 25 Apr 2020 10:10:14 -0400 Steven Rostedt wrote: > Deciding to BUG on not based on the return code of patch_instruction() That was suppose to be "to BUG on or not," -- Steve > is the way to go IMO.

Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()

2020-04-25 Thread Steven Rostedt
On Fri, 24 Apr 2020 14:26:02 -0500 "Christopher M. Riedl" wrote: > On Fri Apr 24, 2020 at 9:15 AM, Steven Rostedt wrote: > > On Thu, 23 Apr 2020 18:21:14 +0200 > > Christophe Leroy wrote: > > > > > > > Le 23/04/2020 à 17:09, Naveen N. Rao

Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()

2020-04-25 Thread Steven Rostedt
On Sat, 25 Apr 2020 10:11:56 + Christophe Leroy wrote: > > Sure it's be more explicit, but then more lines also. 3 lines for only > one really usefull. > > With goto, I would look like: > > diff --git a/arch/powerpc/kernel/optprobes.c > b/arch/powerpc/kernel/optprobes.c > index

Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()

2020-04-24 Thread Steven Rostedt
On Fri, 24 Apr 2020 23:56:25 +0530 "Naveen N. Rao" wrote: > > #define PATCH_INSN(addr, instr) \ > > ({ > > int rc = patch_instruction((unsigned int *)(addr), instr); \ > > if (rc) \ > > pr_err("%s:%d Error

Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()

2020-04-24 Thread Steven Rostedt
On Fri, 24 Apr 2020 23:37:06 +0530 "Naveen N. Rao" wrote: > >> Le 23/04/2020 à 17:09, Naveen N. Rao a écrit : > >> > With STRICT_KERNEL_RWX, we are currently ignoring return value from > >> > __patch_instruction() in do_patch_instruction(), resulting in the error > >> > not being propagated

Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()

2020-04-24 Thread Steven Rostedt
On Thu, 23 Apr 2020 17:41:52 +0200 Christophe Leroy wrote: > > diff --git a/arch/powerpc/kernel/optprobes.c > > b/arch/powerpc/kernel/optprobes.c > > index 024f7aad1952..046485bb0a52 100644 > > --- a/arch/powerpc/kernel/optprobes.c > > +++ b/arch/powerpc/kernel/optprobes.c > > @@ -139,52

Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()

2020-04-24 Thread Steven Rostedt
On Thu, 23 Apr 2020 18:21:14 +0200 Christophe Leroy wrote: > Le 23/04/2020 à 17:09, Naveen N. Rao a écrit : > > With STRICT_KERNEL_RWX, we are currently ignoring return value from > > __patch_instruction() in do_patch_instruction(), resulting in the error > > not being propagated back. Fix the

Re: [RFC PATCH 2/3] powerpc/lib: Initialize a temporary mm for code patching

2020-04-24 Thread Steven Rostedt
On Fri, 17 Apr 2020 10:57:10 +1000 Michael Ellerman wrote: > >>> Does it needs to be a BUG_ON() ? Can't we fail gracefully with just a > >>> WARN_ON ? > >>> > >> > >> I'm not sure what failing gracefully means here? The main reason this could > >> fail is if there is not enough memory to

Re: POWER9 crash due to STRICT_KERNEL_RWX (WAS: Re: Linux-next POWER9 NULL pointer NIP...)

2020-04-16 Thread Steven Rostedt
On Thu, 16 Apr 2020 21:19:10 -0400 Qian Cai wrote: > OK, reverted the commit, > > c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with > RELOCATABLE”) > > or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this > thread, This may be a symptom and not a

Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.

2020-04-09 Thread Steven Rostedt
On Thu, 9 Apr 2020 06:06:35 -0400 Qian Cai wrote: > >> I’ll go to bisect some more but it is going to take a while. > >> > >> $ git log --oneline 4c205c84e249..8e99cf91b99b > >> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in > >> atomic > >> 2ab2a0924b99 tracing:

Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.

2020-04-07 Thread Steven Rostedt
On Tue, 7 Apr 2020 09:01:10 -0400 Qian Cai wrote: > + Steven > > > On Apr 7, 2020, at 8:42 AM, Michael Ellerman wrote: > > > > Qian Cai writes: > >> Ever since 1st Apr, linux-next starts to trigger a NULL pointer NIP on > >> POWER9 below using > >> this config, > >> > >>

Re: "ftrace: Rework event_create_dir()" triggers boot error messages

2020-01-06 Thread Steven Rostedt
On Mon, 6 Jan 2020 12:05:58 -0500 Qian Cai wrote: > > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c > > index 53935259f701..abb70c71fe60 100644 > > --- a/kernel/trace/trace_syscalls.c > > +++ b/kernel/trace/trace_syscalls.c > > @@ -269,7 +269,8 @@ static int __init

Re: "ftrace: Rework event_create_dir()" triggers boot error messages

2019-12-18 Thread Steven Rostedt
On Wed, 18 Dec 2019 22:58:23 -0500 Qian Cai wrote: > The linux-next commit "ftrace: Rework event_create_dir()” [1] triggers boot > warnings > for Clang-build (Clang version 8.0.1) kernels (reproduced on both arm64 and > powerpc). > Reverted it (with trivial conflict fixes) on the top of

Re: powerpc ftrace broken due to "manual merge of the ftrace tree with the arm64 tree"

2019-11-18 Thread Steven Rostedt
On Mon, 18 Nov 2019 09:58:42 -0500 Steven Rostedt wrote: > On Mon, 18 Nov 2019 09:51:04 -0500 > Steven Rostedt wrote: > > > > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022 > > > > > > # git reset --hard b83b43ffc6e4b514ca

Re: powerpc ftrace broken due to "manual merge of the ftrace tree with the arm64 tree"

2019-11-18 Thread Steven Rostedt
On Mon, 18 Nov 2019 09:51:04 -0500 Steven Rostedt wrote: > > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022 > > > > # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022 > > > > Yes, that one is bad. > > Can you se

Re: powerpc ftrace broken due to "manual merge of the ftrace tree with the arm64 tree"

2019-11-18 Thread Steven Rostedt
On Fri, 15 Nov 2019 16:06:34 -0500 Qian Cai wrote: > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022 > > # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022 > > Yes, that one is bad. Can you see if this patch fixes the issue for you? Thanks! -- Steve diff

Re: powerpc ftrace broken due to "manual merge of the ftrace tree with the arm64 tree"

2019-11-15 Thread Steven Rostedt
On Fri, 15 Nov 2019 15:28:52 -0500 Qian Cai wrote: > # echo function >/sys/kernel/debug/tracing/current_tracer > > It hangs forever with today's linux-next on powerpc. Reverted the conflict fix > [1] as below fixes the issue. > > [1] >

Re: [PATCH 00/50] Add log level to show_stack()

2019-11-13 Thread Steven Rostedt
On Wed, 13 Nov 2019 09:47:22 +0100 Petr Mladek wrote: > At the moment, I am in favor of this patchset. It is huge and > needed a lot of manual work. But the result is straightforward and > easy to understand. I'm in favor of this patchset too. If there's other areas that need to adjust the

Re: [PATCH 00/50] Add log level to show_stack()

2019-11-13 Thread Steven Rostedt
On Wed, 6 Nov 2019 23:25:13 + Russell King - ARM Linux admin wrote: > On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote: > > I suppose I'm surprised there are backtraces that are not important. > > Either badness happened and it needs printing, or the user asked for it > > and

Re: [PATCH 00/50] Add log level to show_stack()

2019-11-13 Thread Steven Rostedt
On Wed, 6 Nov 2019 21:34:40 +0100 Peter Zijlstra wrote: > I suppose I'm surprised there are backtraces that are not important. > Either badness happened and it needs printing, or the user asked for it > and it needs printing. Unfortunately that is the case. As my tests will fail if a backtrace

Re: [PATCH 00/50] Add log level to show_stack()

2019-11-13 Thread Steven Rostedt
On Tue, 12 Nov 2019 11:17:47 +0900 Sergey Senozhatsky wrote: > void show_stack(struct task_struct *task, unsigned long *sp, int log_level) > { > printk_emergency_enter(log_level); > __show_stack(task, sp); > printk_emergency_exit(); > } > // - - - - - - - - - - - - - - - - - -

Re: [PATCH 00/50] Add log level to show_stack()

2019-11-13 Thread Steven Rostedt
On Tue, 12 Nov 2019 13:44:47 +0900 Sergey Senozhatsky wrote: > > > I do recall that we talked about per-CPU printk state bit which would > > > start/end "just print it" section. We probably can extend it to "just > > > log_store" type of functionality. Doesn't look like a very bad idea. > > >

Re: [PATCH 1/2] ftrace: Fix NULL pointer dereference in t_probe_next()

2019-08-30 Thread Steven Rostedt
gt; + > size = 1 << hash->size_bits; > > retry: OK, I added this, but I'm also adding this on top: -- Steve From 372e0d01da71c84dcecf7028598a33813b0d5256 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Fri, 30 Aug 2019 16:30:01 -0400 Subject: [P

Re: [PATCH 1/2] ftrace: Fix NULL pointer dereference in t_probe_next()

2019-08-30 Thread Steven Rostedt
On Thu, 4 Jul 2019 20:04:41 +0530 "Naveen N. Rao" wrote: > LTP testsuite on powerpc results in the below crash: > > Unable to handle kernel paging request for data at address 0x > Faulting instruction address: 0xc029d800 > Oops: Kernel access of bad area, sig: 11 [#1] >

Re: [PATCH 0/2] ftrace: two fixes with func_probes handling

2019-08-30 Thread Steven Rostedt
On Thu, 08 Aug 2019 20:45:04 +0530 "Naveen N. Rao" wrote: > Naveen N. Rao wrote: > > Two patches addressing bugs in ftrace function probe handling. The first > > patch addresses a NULL pointer dereference reported by LTP tests, while > > the second one is a trivial patch to address a missing

Re: [PATCH 01/11] ftrace: move recordmcount tools to scripts/ftrace

2019-08-26 Thread Steven Rostedt
On Sun, 25 Aug 2019 21:23:20 +0800 Changbin Du wrote: > Move ftrace tools to its own directory. We will add another tool later. > > Cc: John F. Reiser > Signed-off-by: Changbin Du > --- > scripts/.gitignore | 1 - > scripts/Makefile | 2 +- >

Re: [PATCH 0/2] ftrace: two fixes with func_probes handling

2019-08-08 Thread Steven Rostedt
On Thu, 08 Aug 2019 20:45:04 +0530 "Naveen N. Rao" wrote: > Naveen N. Rao wrote: > > Two patches addressing bugs in ftrace function probe handling. The first > > patch addresses a NULL pointer dereference reported by LTP tests, while > > the second one is a trivial patch to address a missing

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

2019-06-27 Thread Steven Rostedt
is can happen during module load/init and so, I > patch out both instructions in __ftrace_make_call() above without any > synchronization. > > Am I missing anything? > No, I think I got confused ;-), it's the patch out that I was worried about, but when I was going through the scenario, I somehow turned it into the patching in (which I already audited :-p). I was going to reply with just the top part of this email, but then the confusion started :-/ OK, yes, patching out should be fine, and you already covered the patching in. Sorry for the noise. Just to confirm and totally remove the confusion, the patch does: : mflrr0 <-- preempt here bl _mcount : mflrr0 nop And this is fine regardless. OK, Reviewed-by: Steven Rostedt (VMware) -- Steve

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

2019-06-27 Thread Steven Rostedt
On Thu, 27 Jun 2019 16:53:52 +0530 "Naveen N. Rao" wrote: > With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to > enable function tracing and profiling. So far, with dynamic ftrace, we > used to only patch out the branch to _mcount(). However, mflr is > executed by the branch

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

2019-06-27 Thread Steven Rostedt
*rec, int enable) > +int > +ftrace_replace_code_rec(struct dyn_ftrace *rec, int enable) Make this a single line, as it removes static and "__" which should keep it normal. Other than that, Reviewed-by: Steven Rostedt (VMware) -- Steve > { > unsigned long ftrace_old_a

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

2019-06-27 Thread Steven Rostedt
On Thu, 27 Jun 2019 16:53:50 +0530 "Naveen N. Rao" wrote: > In commit a0572f687fb3c ("ftrace: Allow ftrace_replace_code() to be > schedulable), the generic ftrace_replace_code() function was modified to > accept a flags argument in place of a single 'enable' flag. However, the > x86 version of

Re: [PATCH] recordmcount: Fix spurious mcount entries on powerpc

2019-06-27 Thread Steven Rostedt
On Thu, 27 Jun 2019 15:55:47 +1000 Michael Ellerman wrote: > Steve are you OK if I merge this via the powerpc tree? I'll reword the > commit message so that it makes sense coming prior to the commit > mentioned above. Yes, please add: Acked-by: Steven Rostedt (VMware) Thanks, -- Steve

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

2019-06-19 Thread Steven Rostedt
t's indeed nice. I hope you don't mind me adding your SOB for > that. Actually, it's best not to put a SOB by anyone other than yourself. It actually has legal meaning. In this case, please add: Suggested-by: Steven Rostedt (VMware) Thanks! -- Steve

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

2019-06-18 Thread Steven Rostedt
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

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

2019-06-18 Thread Steven Rostedt
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_start; pg; pg =

Re: [PATCH RFC 0/5] Remove some notrace RCU APIs

2019-05-25 Thread Steven Rostedt
On Sat, 25 May 2019 04:14:44 -0400 Joel Fernandes wrote: > > I guess the difference between the _raw_notrace and just _raw variants > > is that _notrace ones do a rcu_check_sparse(). Don't we want to keep > > that check? > > This is true. > > Since the users of _raw_notrace are very few, is

Re: [PATCH RFC 0/5] Remove some notrace RCU APIs

2019-05-24 Thread Steven Rostedt
On Fri, 24 May 2019 19:49:28 -0400 "Joel Fernandes (Google)" wrote: > The series removes users of the following APIs, and the APIs themselves, since > the regular non - _notrace variants don't do any tracing anyway. > * hlist_for_each_entry_rcu_notrace > * rcu_dereference_raw_notrace > I

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

2019-05-20 Thread Steven Rostedt
On Mon, 20 May 2019 20:12:48 +0530 "Naveen N. Rao" wrote: > Thanks, that definitely helps make things clearer. A very small nit from > your first patch -- it would be good to also convert the calls to > ftrace_check_record() to use 'true' or 'false' for the 'update' field. Heh, I was so

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

2019-05-20 Thread Steven Rostedt
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 a

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

2019-05-20 Thread Steven Rostedt
On Sat, 18 May 2019 00:32:46 +0530 "Naveen N. Rao" wrote: > In commit a0572f687fb3c ("ftrace: Allow ftrace_replace_code() to be > schedulable), the generic ftrace_replace_code() function was modified to > accept a flags argument in place of a single 'enable' flag. However, the > x86 version of

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

2019-05-20 Thread Steven Rostedt
On Sat, 18 May 2019 00:32:45 +0530 "Naveen N. Rao" wrote: > 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 Reviewed-b

Re: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-14 Thread Steven Rostedt
On Tue, 14 May 2019 21:13:06 +0200 Geert Uytterhoeven wrote: > > > Do we care about the value? "(-E%u)"? > > > > That too could be confusing. What would (-E22) be considered by a user > > doing an sprintf() on some string. I know that would confuse me, or I > > would think that it was what the

Re: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-14 Thread Steven Rostedt
[ Purple is a nice shade on the bike shed. ;-) ] On Tue, 14 May 2019 11:02:17 +0200 Geert Uytterhoeven wrote: > On Tue, May 14, 2019 at 10:29 AM David Laight wrote: > > > And I like Steven's "(fault)" idea. > > > How about this: > > > > > > if ptr < PAGE_SIZE -> "(null)" >

Re: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-13 Thread Steven Rostedt
On Mon, 13 May 2019 14:42:20 +0200 Petr Mladek wrote: > > The "(null)" is good enough by itself and already an established > > practice.. > > (efault) made more sense with the probe_kernel_read() that > checked wide range of addresses. Well, I still think that > it makes sense to distinguish

Re: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-10 Thread Steven Rostedt
On Fri, 10 May 2019 18:32:58 +0200 Martin Schwidefsky wrote: > On Fri, 10 May 2019 12:24:01 -0400 > Steven Rostedt wrote: > > > On Fri, 10 May 2019 10:42:13 +0200 > > Petr Mladek wrote: > > > > > static const char *check_pointer_msg(const v

Re: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-10 Thread Steven Rostedt
On Fri, 10 May 2019 10:42:13 +0200 Petr Mladek wrote: > static const char *check_pointer_msg(const void *ptr) > { > - char byte; > - > if (!ptr) > return "(null)"; > > - if (probe_kernel_address(ptr, byte)) > + if ((unsigned long)ptr < PAGE_SIZE ||

Re: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-09 Thread Steven Rostedt
On Thu, 9 May 2019 14:19:23 +0200 Petr Mladek wrote: > The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing > invalid pointers") broke boot on several architectures. The common > pattern is that probe_kernel_read() is not working during early > boot because userspace access

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

2019-04-04 Thread Steven Rostedt
On Thu, 4 Apr 2019 21:17:58 +0300 "Dmitry V. Levin" wrote: > There are several places listed below where I'd prefer to see more readable > equivalents, but feel free to leave it to respective arch maintainers. I was going to do similar changes, but figured I'd do just that (let the arch

[PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

2019-04-01 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" At Linux Plumbers, Andy Lutomirski approached me and pointed out that the function call syscall_get_arguments() implemented in x86 was horribly written and not optimized for the standard case of passing in 0 and 6 for the starting index and the number

[PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

2019-04-01 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" After removing the start and count arguments of syscall_get_arguments() it seems reasonable to remove them from syscall_set_arguments(). Note, as of today, there are no users of syscall_set_arguments(). But we are told that there will be soon. B

Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()

2019-03-29 Thread Steven Rostedt
[ Added Peter ] On Fri, 29 Mar 2019 19:13:55 +1000 Nicholas Piggin wrote: > Suraj Jitindar Singh's on March 29, 2019 3:20 pm: > > On Wed, 2019-03-27 at 17:51 +0100, Cédric Le Goater wrote: > >> On 3/27/19 5:37 PM, Cédric Le Goater wrote: > >> > On 3/27/19 1:36 PM, Sebastian Andrzej Siewior

[RFC][PATCH 4/4 v2] syscalls: Remove start and number from syscall_set_arguments() args

2019-03-28 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" After removing the start and count arguments of syscall_get_arguments() it seems reasonable to remove them from syscall_set_arguments(). Note, as of today, there are no users of syscall_set_arguments(). But we are told that there will be soon. B

[RFC][PATCH 3/4 v2] syscalls: Remove start and number from syscall_get_arguments() args

2019-03-28 Thread Steven Rostedt
From: "Steven Rostedt (Red Hat)" At Linux Plumbers, Andy Lutomirski approached me and pointed out that the function call syscall_get_arguments() implemented in x86 was horribly written and not optimized for the standard case of passing in 0 and 6 for the starting index and the number

Re: [PATCH] kbuild: strip whitespace in cmd_record_mcount findstring

2019-03-25 Thread Steven Rostedt
roblem. > > Fixes: 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer"). > Signed-off-by: Joe Lawrence Acked-by: Steven Rostedt (VMware) -- Steve > --- > > Standard disclaimer: I'm not a kbuild expert, but this works around the > problem I reported

Re: ppc64le: ftrace self-tests and $(CC_FLAGS_FTRACE) broken?

2019-03-23 Thread Steven Rostedt
On Sat, 23 Mar 2019 09:19:50 -0400 Joe Lawrence wrote: > Perhaps this is gcc version specific? I didn't see any other reports, > so maybe its specific to my config. If I run make V=1, I can see that > gcc is called with '-pg -mprofile-kernel', but then the record_mcount > script is skipped.

Re: [PATCH v3 1/7] dump_stack: Support adding to the dump stack arch description

2019-02-08 Thread Steven Rostedt
On Thu, Feb 07, 2019 at 11:46:29PM +1100, Michael Ellerman wrote: > > diff --git a/include/linux/printk.h b/include/linux/printk.h > index 77740a506ebb..d5fb4f960271 100644 > --- a/include/linux/printk.h > +++ b/include/linux/printk.h > @@ -198,6 +198,7 @@ u32 log_buf_len_get(void); > void

Re: [for-next][PATCH 05/24] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

2018-12-22 Thread Steven Rostedt
On Sat, 22 Dec 2018 20:51:21 +1100 Michael Ellerman wrote: > I did test the previous series you posted and I think everything was OK > running the ftracetest suite (I got one or two fails but I think that > was because of missing CONFIG options). > > Acked-by: Michael Ellerman (powerpc)

[for-next][PATCH 05/24] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

2018-12-21 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures mu

Re: trace_hardirqs_on/off vs. extra stack frames

2018-12-20 Thread Steven Rostedt
On Fri, 21 Dec 2018 12:11:35 +1100 Benjamin Herrenschmidt wrote: > Hi Steven ! > > I'm trying to untangle something, and I need your help :-) > > In commit 3cb5f1a3e58c0bd70d47d9907cc5c65192281dee, you added a summy > stack frame around the assembly calls to trace_hardirqs_on/off on the >

[PATCH 3/6] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

2018-12-10 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" [ Folks, I'm working on rewriting the function graph tracer. In order to do so, some changes need to be done that affect architecture specific code. I'm only able to compile test these changes. I would like to have folks check out my repo and

[for-next][PATCH 09/18] powerpc/function_graph: Simplify with function_graph_entry()

2018-11-21 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" The function_graph_entry() function does the work of calling the function graph hook function and the management of the shadow stack, simplifying the work done in the architecture dependent prepare_ftrace_return(). Have powerpc use the new code,

Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/

2018-09-06 Thread Steven Rostedt
On Thu, 6 Sep 2018 09:58:04 -0600 Jonathan Corbet wrote: > Thanks, > > jon (who is increasingly inclined to apply this patch) As Colin Kaepernick now says... "Just do it!" ;-) -- Steve

Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/

2018-09-04 Thread Steven Rostedt
On Tue, 4 Sep 2018 13:30:30 +0200 Pavel Machek wrote: > I'd say this is still quite valueable, and it might be worth fixing, > rather then removing completely. I agree. Perhaps we should have a 00-DESCRIPTION file in each directory, and each file could start with a: DESCRIPTION: and then

Re: [PATCH v3 3/4] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS

2018-05-15 Thread Steven Rostedt
port ppc to that. It is also no my todo list to merge that with objtool. Anyway, Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org> -- Steve > diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl > index 191eb949d52c..3c67304a7425 100755 > --- a/scripts/record

Re: [PATCH v3 3/4] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS

2018-05-14 Thread Steven Rostedt
On Mon, 14 May 2018 13:52:27 +1000 Nicholas Piggin wrote: > The powerpc toolchain can compile combinations of 32/64 bit and > big/little endian, so it's convenient to consider, e.g., > > `CC -m64 -mbig-endian` > > To be the C compiler for the purpose of invoking it to

Re: [PATCH] tracing: Remove PPC32 wart from config TRACING_SUPPORT

2018-05-02 Thread Steven Rostedt
support for 32-bit powerpc") (Jun 2009). > > So remove the exception for PPC32 and the comment. > > Signed-off-by: Michael Ellerman <m...@ellerman.id.au> Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org> Feel free to take this patch through the PPC tree

Re: [PATCH v5 06/10] powerpc64/ftrace: Disable ftrace during kvm entry/exit

2018-04-19 Thread Steven Rostedt
On Thu, 19 Apr 2018 12:34:05 +0530 "Naveen N. Rao" wrote: > 2. If we are a secondary thread in Power8, then we would be in nap due > to SMT being disabled. We are woken up by an IPI to enter the guest. In > this scenario, we enter the guest through

  1   2   3   4   5   >