Can I get an Acked-by from the POWERPC maintainers for this patch?
Thanks!
-- Steve
[ Note this is modifies the return side ]
On Fri, 13 Sep 2024 00:09:02 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Pass ftrace_regs to the fgraph_ops::retfunc(). If ftrac
Can I get an Acked-by from the POWERPC maintainers for this patch?
Thanks!
-- Steve
On Fri, 13 Sep 2024 00:08:40 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Pass ftrace_regs to the fgraph_ops::entryfunc(). If ftrace_regs is not
> available, it passes a N
On Mon, 9 Sep 2024 17:34:48 +0300
Mike Rapoport wrote:
> > This is insane, just force BUILDTIME_MCOUNT_SORT
>
> The comment in ftrace.c says "... while mcount loc in modules can not be
> sorted at build time"
>
> I don't know enough about objtool, but I'd presume it's because the sorting
> s
On Mon, 26 Aug 2024 09:55:29 +0300
Mike Rapoport wrote:
> From: Song Liu
>
> ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
> ftrace_swap_func so that archs can use RO-memory-poke function to do the
> sorting.
Can you add the above as a comment above the ftrace_swap_
On Tue, 11 Jun 2024 20:17:19 +0530
Naveen N Rao wrote:
> > I know it's very unlikely, but in theory, I think the race exists.
>
> I *think* you are assuming that we will be patching back the 'stw'
Yes, that was what I was assuming :-p
> instruction here? So, there could be an issue if a cpu
I noticed a slight bug in ftrace_graph_ret_addr() for when
HAVE_FUNCTION_GRAPH_RET_ADDR_PTR was defined and fixed it up.
I then noticed it was buggy when not defined. Looking for an
architecture that did not have it defined, I couldn't find any.
So I removed it.
Steven Rostedt (Googl
From: "Steven Rostedt (Google)"
All architectures that implement function graph also implements
HAVE_FUNCTION_GRAPH_RET_ADDR_PTR. Remove it, as it is no longer a
differentiator.
Signed-off-by: Steven Rostedt (Google)
---
Documentation/trace/ftrace-design.rst | 12 -
arch/arm
From: "Steven Rostedt (Google)"
Yang Li sent a patch to fix the kerneldoc of ftrace_graph_ret_addr().
While reviewing it, I realized that the comments in the entire function
header needed a rewrite. When doing that, I realized that @idx parameter
was being ignored. Every time this was
On Mon, 10 Jun 2024 14:08:16 +0530
Naveen N Rao wrote:
> On 32-bit powerpc, gcc generates a three instruction sequence for
> function profiling:
> mflrr0
> stw r0, 4(r1)
> bl _mcount
>
> On kernel boot, the call to _mcount() is nop-ed out, to be patched back
> in w
On Mon, 10 Jun 2024 14:08:15 +0530
Naveen N Rao wrote:
> Pointer to struct module is only relevant for ftrace records belonging
> to kernel modules. Having this field in dyn_arch_ftrace wastes memory
> for all ftrace records belonging to the kernel. Remove the same in
> favour of looking up the m
On Tue, 04 Jun 2024 10:45:37 +0300
Jani Nikula wrote:
> On Sun, 02 Jun 2024, Andy Shevchenko
> wrote:
> > Make two APIs look similar. Hence convert match_string() to be
> > a 2-argument macro. In order to avoid unneeded churn, convert
> > all users as well. There is no functional change intende
On Fri, 17 May 2024 10:36:37 -0700
Guenter Roeck wrote:
> Building csky:allmodconfig (and others) ... failed
> --
> Error log:
> In file included from include/trace/trace_events.h:419,
> from include/trace/define_trace.h:102,
> from drivers/cxl/core/t
On Mon, 6 May 2024 14:46:57 +
Christophe Leroy wrote:
> Isn't it safer to provide a fonction rather than a direct access to a
> variable ?
>
> By the way, wouldn't it be more performant to use a static branch (jump
> label) ?
A static branch could work, but the point of this is that if ft
| 10 --
> 2 files changed, 1 insertion(+), 10 deletions(-)
Reviewed-by: Steven Rostedt (Google)
-- Steve
Trampolines can only be created if modules are supported */
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
Acked-by: Steven Rostedt (Google)
-- Steve
eave a ticking time bomb.
>
> Signed-off-by: Stephen Brennan
> ---
> Changes in v3:
> Don't expose ftrace_is_dead(). Create a "kprobe_ftrace_disabled"
> variable and check it directly in the kprobe handlers.
Reviewed-by: Steven Rostedt (Google)
Thanks,
-- Steve
On Mon, 29 Apr 2024 10:47:18 -0700
Stephen Brennan wrote:
> If an error happens in ftrace, ftrace_kill() will prevent disarming
> kprobes. Eventually, the ftrace_ops associated with the kprobes will be
> freed, yet the kprobes will still be active, and when triggered, they
> will use the freed me
On Thu, 14 Mar 2024 09:57:57 -0700
Alison Schofield wrote:
> On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > [
> >This is a treewide change. I will likely re-create this patch again in
> >
On Tue, 27 Feb 2024 11:56:14 -0500
Steven Rostedt wrote:
> On Tue, 27 Feb 2024 22:08:18 +0530
> Sachin Sant wrote:
>
> > > Can you apply this, and see if it triggers and if it does, print the line
> > > that has the max size?
> > >
>
On Tue, 27 Feb 2024 22:08:18 +0530
Sachin Sant wrote:
> > Can you apply this, and see if it triggers and if it does, print the line
> > that has the max size?
> >
>
> With this I see following trace
>
> [ 61.327138] [ cut here ]
> [ 61.327159] MAX OUT OF RANGE 634
On Tue, 27 Feb 2024 21:38:57 +0530
Sachin Sant wrote:
> This warning was not triggered.
Interesting.
>
> I have attached .config
This is what I was looking for:
> # CONFIG_PPC_4K_PAGES is not set
> CONFIG_PPC_64K_PAGES=y
> CONFIG_PAGE_SIZE_64KB=y
> CONFIG_PPC_PAGE_SHIFT=16
So the pages are
On Tue, 27 Feb 2024 15:06:18 +0530
Sachin Sant wrote:
> I used this setup to again run bisect between 6.7.0 and 6.8-rc1.
> Bisect points to following patch
>
> commit 8ec90be7f15fac42992ea821be929d3b06cd0fd9
> tracing: Allow for max buffer data size trace_marker writes
Thanks, that was wha
On Sun, 25 Feb 2024 22:01:50 +0530
Sachin Sant wrote:
> While running ftrace specific kernel selftests following warning
> is seen on a Power10 logical partition (LPAR) booted with
> latest mainline kernel.
>
> [ cut here ]
> precision 63492 too large
> WARNING: CPU: 15 P
On Fri, 23 Feb 2024 13:46:53 -0500
Steven Rostedt wrote:
> Now one thing I could do is to not remove the parameter, but just add:
>
> WARN_ON_ONCE((src) != __data_offsets->item##_ptr_);
>
> in the __assign_str() macro to make sure that it's still the same that is
On Fri, 23 Feb 2024 14:50:49 -0500
Kent Overstreet wrote:
> Tangentially related though, what would make me really happy is if we
> could create the string with in the TP__fast_assign() section. I have to
> have a bunch of annoying wrappers right now because the string length
> has to be known wh
On Fri, 23 Feb 2024 10:30:45 -0800
Jeff Johnson wrote:
> On 2/23/2024 9:56 AM, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > [
> >This is a treewide change. I will likely re-create this patch again in
> >the second week of
On Fri, 23 Feb 2024 12:56:34 -0500
Steven Rostedt wrote:
> Note, the same updates will need to be done for:
>
> __assign_str_len()
> __assign_rel_str()
> __assign_rel_str_len()
Correction: The below macros do not pass in their source to the entry
macros, so they will
On Thu, 21 Dec 2023 10:46:08 +
Christophe Leroy wrote:
> > To enable ftrace, the nop at function entry is changed to an
> > unconditional branch to 'tramp'. The call to ftrace_caller() may be
> > updated to ftrace_regs_caller() depending on the registered ftrace ops.
> > On 64-bit powerpc, we
On Thu, 19 Oct 2023 04:07:35 +0800
kernel test robot wrote:
> Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml:
> Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml:
> fs/tracefs/event_inode.c:782:11-21: ERROR: ei is NULL but dereferenced.
This was already reported and I'm currently test
On Fri, 21 Jul 2023 18:06:07 +0200
Alexander Lobakin wrote:
> > Just because you disable interrupts does not mean you are in interrupt
> > context.
>
> Ah okay, thanks! IOW, if we want to check in some code that we're
> certainly have interrupts enabled and are not in the interrupt context,
>
On Fri, 21 Jul 2023 17:34:41 +0200
Alexander Lobakin wrote:
> From: Steven Rostedt
> Date: Fri, 15 Oct 2021 14:25:41 -0400
>
> Sorry for such a necroposting :z
> Just wanted to know if this is a bug, so that I could send a fix, or
> intended behaviour.
>
> > On Fri,
On Wed, 21 Jun 2023 10:45:05 -0400
Jeff Layton wrote:
> Most of this conversion was done via coccinelle, with a few of the more
> non-standard accesses done by hand. There should be no behavioral
> changes with this set. That will come later, as we convert individual
> filesystems to use multigra
On Mon, 19 Jun 2023 02:43:58 +0200
Thomas Gleixner wrote:
> Now you might argue that it _is_ a "hotpath" due to the BPF usage, but
> then even more so as any intermediate wrapper which converts from one
> data representation to another data representation is not going to
> increase performance, r
On Thu, 1 Jun 2023 16:54:36 -0700
Nadav Amit wrote:
> > The way text_poke() is used here, it is creating a new writable alias
> > and flushing it for *each* write to the module (like for each write of
> > an individual relocation, etc). I was just thinking it might warrant
> > some batching or so
On Sat, 20 May 2023 23:58:01 +0530
Naveen N Rao wrote:
> >
> > At the begining of ftrace_replace_code(), don't you miss:
> >
> > if (unlikely(ftrace_disabled))
> > return;
>
> ftrace_disabled is a static, so it can't be tested here. FWIW, x86 also
> implements ftrace_replace
On Tue, 14 Feb 2023 10:23:22 -0800
Josh Poimboeuf wrote:
> void __ref cpu_die(void)
> {
> idle_task_exit();
> local_irq_disable();
> __asm__ __volatile__(
> " movia2, cpu_restart\n"
> " jx a2\n");
>
> BUG()
good starting point.
For the tracing portions:
Reviewed-by: Steven Rostedt (Google)
-- Steve
On Tue, 11 Oct 2022 17:40:26 +0100
Valentin Schneider wrote:
> > You could keep the tracepoint as a mask, and then make it pretty, like
> > cpus=3-5,8
> > in user-space. For example with a trace-cmd/perf loadable plugin,
> > libtracefs helper.
> >
>
> That's a nice idea, the one downside I s
On Tue, 11 Oct 2022 17:17:04 +0100
Valentin Schneider wrote:
> tep_get_field_val() just yields an unsigned long long of value 0x200018,
> which AFAICT is just the [length, offset] thing associated with dynamic
> arrays. Not really usable, and I don't see anything exported in the lib to
> extract
On Fri, 7 Oct 2022 17:01:33 -0300
Marcelo Tosatti wrote:
> > As for the targeted CPUs, the existing tracepoint does export them, albeit
> > in
> > cpumask form, which is quite inconvenient from a tooling perspective. For
> > instance, as far as I'm aware, it's not possible to do event filtering
On Fri, 7 Oct 2022 16:45:32 +0100
Valentin Schneider wrote:
> }
>
> +static inline void irq_work_raise(void)
> +{
> + if (arch_irq_work_has_interrupt())
> + trace_ipi_send_cpu(_RET_IP_, smp_processor_id());
To save on the branch, let's make the above:
if (trace_ipi_se
Nit, the subject should have "tracing:" an not "ftrace:" as the former
encompasses the tracing infrastructure and the latter is for the function
hook part of that.
On Mon, 19 Sep 2022 12:00:12 +0200
Peter Zijlstra wrote:
> CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
> ena
ded by
> 'mflr r0' and 'stw r0,4(r1)'.
>
> With this patch, and with ppc64le_guest_defconfig and some ftrace/bpf
> config items enabled:
> # grep __ftrace_invalid_address available_filter_functions | wc -l
> 79
I wonder if this patch answers the question
On Wed, 27 Apr 2022 15:01:20 +0530
"Naveen N. Rao" wrote:
> This solves a build issue on powerpc with binutils v2.36 and newer [1].
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [2], binutils started dropping section symbols that it thought
> were unused. Due to t
.com, yury.no...@gmail.com, ulli.kr...@googlemail.com, vgu...@kernel.org,
linux-...@vger.kernel.org, mon...@monstr.eu, r...@vger.kernel.org,
b...@alien8.de, bc...@quicinc.com, tsbog...@alpha.franken.de,
linux-par...@vger.kernel.org, sudeep.ho...@arm.com, shawn...@kernel.org,
da...@davemloft.net
On Thu, 28 Apr 2022 09:01:13 +0800
Xiaoming Ni wrote:
> > +#ifdef CONFIG_DEBUG_NOTIFIERS
> > + {
> > + char sym_name[KSYM_NAME_LEN];
> > +
> > + pr_info("notifiers: registered %s()\n",
> > + notifier_name(n, sym_name));
> > + }
>
> Duplicate Code.
>
>
On Tue, 10 May 2022 13:38:39 +0200
Petr Mladek wrote:
> As already mentioned in the other reply, panic() sometimes stops
> the other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
>
> Another situation is when the CPU using the lock ends in some
> infinite loop because something we
On Wed, 27 Apr 2022 19:49:17 -0300
"Guilherme G. Piccoli" wrote:
> Currently we don't have a way to check if there are dumpers set,
> except counting the list members maybe. This patch introduces a very
> simple helper to provide this information, by just keeping track of
> registered/unregistere
On Wed, 4 May 2022 16:50:58 +
Christophe Leroy wrote:
> In vmlinux, relocations are resolved, trampolines are installed for
> unreachable destinations and you don't anymore have a section with all
> the relocations to mcount. It means 'recordmcount' or whatever tool we
> use will have to r
On Tue, 3 May 2022 11:20:22 +
Christophe Leroy wrote:
> Maybe I misunderstood. When you say 'after linking', do you mean vmlinux
> or vmlinux.o ?
Whichever ;-)
>
> In vmlinux, the addresses to be saved in __mcount_loc table might not
> contain anymore a call to _mcount but a call to a tr
On Mon, 2 May 2022 14:44:56 +
Christophe Leroy wrote:
> If we do that after the linking, won't it be a nightmare with the
> trampolines installed by the linker when the destination is over the 24
> bits limit ?
Not sure what you mean. The locations I'm talking about is the full
address sav
On Sat, 30 Apr 2022 01:03:01 +0530
"Naveen N. Rao" wrote:
> > The point of this section is to know which functions in __mcount_loc may
> > have been overridden, as they would be found in the __mcount_loc_weak
> > section. And then we can do something "special" to them.
>
> I'm not sure I follo
On Fri, 29 Apr 2022 23:09:19 +0530
"Naveen N. Rao" wrote:
> If I'm understanding your suggestion right:
> - we now create a new section in each object file: __mcount_loc_weak,
> and capture such relocations using weak symbols there.
Yes, but it would be putting the same information it puts in
On Fri, 29 Apr 2022 10:46:35 -0300
"Guilherme G. Piccoli" wrote:
> Thanks Sergei and Steven, good idea! I thought about the switch change
> you propose, but I confess I got a bit confused by the "fallthrough"
> keyword - do I need to use it?
No. The fallthrough keyword is only needed when there'
Why not:
>
> case DIE_OOPS:
> case PANIC_NOTIFIER:
> do_dump = 1;
> break;
Agreed.
Other than that.
Acked-by: Steven Rostedt (Google)
-- Steve
On Thu, 28 Apr 2022 22:49:52 +0530
"Naveen N. Rao" wrote:
> But, with ppc64 elf abi v1 which only supports the old -pg flag, mcount
> location can differ between the weak and non-weak variants of a
> function. In such scenarios, one of the two mcount entries will be
> invalid. Such architectures
On Thu, 28 Apr 2022 13:15:22 +0530
"Naveen N. Rao" wrote:
> Indeed, plain old -pg will be a problem. I'm not sure there is a generic
> way to address this. I suppose architectures will have to validate the
> mcount locations, something like this?
Perhaps another solution is to make the mcount
On Wed, 27 Apr 2022 15:01:22 +0530
"Naveen N. Rao" wrote:
> If one or both of these weak functions are overridden in future, in the
> final vmlinux mcount table, references to these will change over to the
> non-weak variant which has its own mcount location entry. As such, there
> will now be tw
On Wed, 27 Apr 2022 15:01:21 +0530
"Naveen N. Rao" wrote:
> In the absence of section symbols [1], objtool (today) and recordmcount
> (with a subsequent patch) generate __mcount_loc relocation records with
> weak symbols as the base. This works fine as long as those weak symbols
> are not overrid
On Mon, 18 Apr 2022 11:51:16 +0530
"Naveen N. Rao" wrote:
> > --- a/arch/powerpc/kernel/trace/ftrace.c
> > +++ b/arch/powerpc/kernel/trace/ftrace.c
> > @@ -78,10 +78,7 @@ ftrace_modify_code(unsigned long ip, ppc_inst_t old,
> > ppc_inst_t new)
> > }
> >
> > /* replace the text with the
On Wed, 30 Mar 2022 06:55:26 +
Christophe Leroy wrote:
> > Small nit. Please order the includes in "upside-down x-mas tree" fashion:
> >
> > #include
> > #include
> > #include
> > #include
> >
>
> That's the first time I get such a request. Usually people request
> #includes to be i
On Fri, 25 Mar 2022 09:03:08 +0100
Christophe Leroy wrote:
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
Small nit. Please order the includes in "upside-down x-mas tree" fashion:
#include
#include
#inclu
s containing
> 'ftrace' as part of the name but with some prefix or suffix.
Acked-by: Steven Rostedt (Google)
-- Steve
On Thu, 24 Mar 2022 11:01:45 +0100
Christophe Leroy wrote:
> @@ -1006,7 +1006,20 @@ unsigned long ftrace_graph_ret_addr(struct task_struct
> *task, int *idx,
> extern int register_ftrace_graph(struct fgraph_ops *ops);
> extern void unregister_ftrace_graph(struct fgraph_ops *ops);
>
> -extern
On Thu, 24 Mar 2022 15:38:28 +0100
Christophe Leroy wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e127c2fb08a7..3b5943f34568 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19592,6 +19592,7 @@ T:git
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> F:
On Thu, 24 Feb 2022 15:13:12 +
Christophe Leroy wrote:
> > But I'm working on a series to send to Linus. I can pick this patch up, as
> > it touches just my code.
> >
>
> That would be great, thanks.
It's in my queue and running through my tests, which take 7 to 13 hours to
complete (dep
On Thu, 24 Feb 2022 13:43:02 +
Christophe Leroy wrote:
> Hi Michael,
>
> Le 20/12/2021 à 17:38, Christophe Leroy a écrit :
> > CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS is required to test
> > direct tramp.
> >
> > Signed-off-by: Christophe Leroy
>
> You didn't apply this patch when you m
On Tue, 15 Feb 2022 19:06:48 +0530
"Naveen N. Rao" wrote:
> As I understand it, the reason ftrace_get_regs() was introduced was to
> be able to only return the pt_regs, if _all_ registers were saved into
> it, which we don't do when coming in through ftrace_caller(). See the
> x86 implementati
On Mon, 14 Feb 2022 22:54:23 +0530
"Naveen N. Rao" wrote:
> For x86, commit 0c0593b45c9b4e ("x86/ftrace: Make function graph use
> ftrace directly") also adds recursion check before the call to
> function_graph_enter() in prepare_ftrace_return(). Do we need that on
> powerpc as well?
Yes. The
On Thu, 10 Feb 2022 16:40:28 +
"Naveen N. Rao" wrote:
> The other option is to mark ftrace_cmp_recs() as a __weak function, but
> I have a vague recollection of you suggesting #ifdef rather than a
> __weak function in the past. I might be mis-remembering, so if you think
> making this a __
On Thu, 10 Feb 2022 13:58:29 +
"Naveen N. Rao" wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index f9feb197b2daaf..68f20cf34b0c47 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1510,6 +1510,7 @@ ftrace_ops_test(struct ftrace_ops *ops, unsigned
On Wed, 09 Feb 2022 17:50:09 +
"Naveen N. Rao" wrote:
> However, I think we will not be able to use a fixed range. I would like
> to reserve instructions from function entry till the branch to
> _mcount(), and it can be two or four instructions depending on whether a
> function has a glob
On Mon, 7 Feb 2022 12:37:21 +0530
"Naveen N. Rao" wrote:
> --- a/arch/powerpc/kernel/trace/ftrace.c
> +++ b/arch/powerpc/kernel/trace/ftrace.c
> @@ -1137,3 +1137,14 @@ char *arch_ftrace_match_adjust(char *str, const char
> *search)
> return str;
> }
> #endif /* PPC64_ELF_ABI_v1
On Fri, 28 Jan 2022 16:11:39 -0500
Joe Lawrence wrote:
> The bisect finally landed on:
>
> 72b3942a173c387b27860ba1069636726e208777 is the first bad commit
> commit 72b3942a173c387b27860ba1069636726e208777
> Author: Yinan Liu
> Date: Sun Dec 12 19:33:58 2021 +0800
>
> scripts:
From f7d4ef4e77464e08af38789ea5d3a9cfb80a3d78 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Google)"
Date: Tue, 25 Jan 2022 09:19:10 -0500
Subject: [PATCH] ftrace: Have architectures opt-in for mcount build time
sorting
First S390 complained that the sorting of the mcount section
From: "Steven Rostedt (Google)"
First S390 complained that the sorting of the mcount sections at build
time caused the kernel to crash on their architecture. Now PowerPC is
complaining about it too. And also ARM64 appears to be having issues.
It may be necessary to also update the
On Thu, 27 Jan 2022 13:33:02 +
Mark Rutland wrote:
> I want to get the regression fixed ASAP, so can we take a simple patch for
> -rc2
> which disables the build-time sort where it's currently broken (by limiting
> the
> opt-in to arm and x86), then follow-up per-architecture to re-enable i
On Thu, 27 Jan 2022 12:27:04 +
Mark Rutland wrote:
> Ah, so those non-ELF relocations for the mcount_loc table just mean "apply the
> KASLR offset here", which is equivalent for all entries.
>
> That makes sense, thanks!
And this is why we were having such a hard time understanding each oth
On Tue, 25 Jan 2022 09:30:51 +0530
Sachin Sant wrote:
> Tested-by: Sachin Sant
Thanks, I'll start running it through my tests and send it to Linus later
today or tomorrow.
-- Steve
On Mon, 24 Jan 2022 20:15:06 +0800
Yinan Liu wrote:
> Hi, Steven and Sachin
>
> I don't have a powerpc machine for testing, I guess the ppc has a
> similar problem with the s390. It's not clear to me why the compiler
> does this. Maybe we can handle ppc like you did with the s390 before,
> bu
On Tue, 14 Dec 2021 08:35:14 +0100
Christophe Leroy wrote:
> > Will continue investigating.
> >
>
> trace_selftest_startup_function_graph() calls register_ftrace_direct()
> which returns -ENOSUPP because powerpc doesn't select
> CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS.
>
> Should TEST_DIRE
On Mon, 13 Dec 2021 19:33:47 +
Christophe Leroy wrote:
> STill the same Oops, below
Unfortunately, I don't have a PPC machine (32 nor 64 bit) to help debug
this.
> I will look more closely tomorrow.
OK, thanks.
-- Steve
On Mon, 13 Dec 2021 17:50:52 +
Christophe Leroy wrote:
> @@ -958,6 +942,12 @@ unsigned long prepare_ftrace_return(unsigned long
> parent, unsigned long ip,
> out:
> return parent;
> }
> +
> +void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
> +st
On Mon, 13 Dec 2021 17:30:48 +
Christophe Leroy wrote:
> Thanks, I will try that.
>
> I can't find ftrace_graph_func() in s390. Does it mean that s390 doesn't
> have a working function tracer anymore ?
>
> I see your commit 0c0593b45c9b4 ("x86/ftrace: Make function graph use
> ftrace dire
On Mon, 13 Dec 2021 14:39:15 +
Christophe Leroy wrote:
> > Note, you can implement this first, (I looked over the patches and they
> > seem fine) and then update both ppc64 and ppc32 to implement
> > DYNAMIC_FTRACE_WITH_ARGS.
> >
>
> I tried to activate DYNAMIC_FTRACE_WITH_ARGS on PPC32.
On Fri, 26 Nov 2021 08:43:23 +
LEROY Christophe wrote:
> Le 24/11/2021 à 15:43, Christophe Leroy a écrit :
> > Looks like recent binutils (2.36 and over ?) may empty some section,
> > leading to failure like:
> >
> > Cannot find symbol for section 11: .text.unlikely.
> > kernel/kexec
kernel/trace/trace.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
Reviewed-by: Steven Rostedt (VMware)
-- Steve
On Mon, 8 Nov 2021 15:35:50 +0100
Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> > I guess I can add another indirection to notifier_chain_register() and
> > avoid touching all the call sites.
>
> IOW, something like this below.
>
> This way I won'
On Thu, 28 Oct 2021 14:24:00 +0200
Christophe Leroy wrote:
> This series implements livepatch on PPC32.
>
> This is largely copied from what's done on PPC64.
>
> Christophe Leroy (5):
> livepatch: Fix build failure on 32 bits processors
> powerpc/ftrace: No need to read LR from stack in _mc
On Wed, 27 Oct 2021 10:34:13 +0800
王贇 wrote:
> +/*
> + * Preemption will be enabled (if it was previously enabled).
> + */
> static __always_inline void trace_clear_recursion(int bit)
> {
> + WARN_ON_ONCE(bit < 0);
Can you send a v7 without the WARN_ON.
This is an extremely hot path, and
On Wed, 27 Oct 2021 09:54:13 +0800
王贇 wrote:
> My apologize for the stupid comments... I'll send a v6 for this patch
> only to fix that, please let me know if this is not a good way to fix
> few lines of comments.
Actually, please resend both patches, as a new patch set, on its own thread.
Just
On Tue, 26 Oct 2021 17:48:10 +0800
王贇 wrote:
> > The two comments should be updated too since Steven removed the "bit == 0"
> > trick.
>
> Could you please give more hint on how will it be correct?
>
> I get the point that bit will no longer be 0, there are only -1 or > 0 now
> so trace_test
On Tue, 26 Oct 2021 10:09:12 +0800
王贇 wrote:
> Just a ping, to see if there are any more comments :-P
I guess you missed what went into mainline (and your name found a bug
in my perl script for importing patches ;-)
https://lore.kernel.org/all/20211019091344.65629...@gandalf.local.home/
Whic
On Tue, 19 Oct 2021 08:41:23 +0200
Petr Mladek wrote:
> Feel free to postpone this change. I do not want to complicate
> upstreaming the fix for stable. I am sorry if I already
> complicated it.
>
No problem. It's not that complicated of a merge fix. I'm sure Linus can
handle it ;-)
-- Steve
On Mon, 18 Oct 2021 12:19:20 +0200
Petr Mladek wrote:
> > -
> > bit = trace_get_context_bit() + start;
> > if (unlikely(val & (1 << bit))) {
> > /*
> > * It could be that preempt_count has not been updated during
> > * a switch between contexts. Allow
On Mon, 18 Oct 2021 15:44:12 -0400
Steven Rostedt (by way of Steven Rostedt
) wrote:
> [
>Linus,
> I have patches that clean this up that are not marked for stable, but
> will depend on this patch. As I already have commits in my next queue,
> I can do one o
of the mainline tag my next branch is based on and
merge it.
3. Add this to my next branch, and have it go in at the next merge
window.
]
From: "Steven Rostedt (VMware)"
While writing an email explaining the "bit = 0" logic for a discussion on
making ftrace_te
On Mon, 18 Oct 2021 12:19:20 +0200
Petr Mladek wrote:
> On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)"
> >
> > While writing an email explaining the "bit = 0" logic for a discussion on
> > making ftrace
On Fri, 15 Oct 2021 20:24:59 +0200
Peter Zijlstra wrote:
> > @@ -206,11 +206,7 @@ DEFINE_OUTPUT_COPY(__output_copy_user,
> > arch_perf_out_copy_user)
> > static inline int get_recursion_context(int *recursion)
> > {
> > unsigned int pc = preempt_count();
>
> Although I think we can do w
On Fri, 15 Oct 2021 14:20:33 -0400
Steven Rostedt wrote:
> > I think having one copy of that in a header is better than having 3
> > copies. But yes, something along them lines.
>
> I was just about to ask you about this patch ;-)
Except it doesn't build :-p (n
1 - 100 of 606 matches
Mail list logo
