From: Steven Rostedt
The power_domain_target event event is only called when CONFIG_OMAP2PLUS
is defined. As each event can take up to 5K regardless if they are used or
not, it's best not to define them when they are not used. Add #ifdef
around these events when they are not used.
Signed-o
used.
The powernv_throttle event is only used by the powernv code so I moved it to
its own header file and it gets created when the powernv code is compiled in.
For the other power events, I just added #ifdef around them with the configs
that enable them.
Steven Rostedt (4):
PM: cpufreq: po
From: Steven Rostedt
The events psci_domain_idle_enter and psci_domain_idle_exit events are
only called when CONFIG_ARM_PSCI_CPUIDLE is defined. As each event can
take up to 5K (less for DEFINE_EVENT()) regardless if they are used or
not, it's best not to define them when they are not used
From: Steven Rostedt
As the trace event powernv_throttle is only used by the powernv code, move
it to a separate include file and have that code directly enable it.
Trace events can take up around 5K of memory when they are defined
regardless if they are used or not. It wastes memory to have
From: Steven Rostedt
The events device_pm_callback_start and device_pm_callback_end events are
only called when CONFIG_PM_SLEEP is defined. As each event can take up to
5K regardless if they are used or not, it's best not to define them when
they are not used. Add #ifdef around these events
On Mon, 31 Mar 2025 21:19:36 +0800
Shung-Hsi Yu wrote:
> Hi all,
>
> On ppc64le (v6.14, kernel config attached), I've observed that fentry
> BPF programs stop being invoked after the target kernel function is live
> patched. This occurs regardless of whether the BPF program was attached
> before
Sorry for the late reply. Forgot about this as I was focused on other
end-of-year issues.
On Sat, 14 Dec 2024 16:37:59 +0800
Zheng Yejian wrote:
> The direct cause of this issue is the wrong fentry being founded by
> ftrace_location(),
> following the approach of "FTRACE_MCOUNT_MAX_OFFSET",
nts_sysctl(const struct
> ctl_table *table, int write,
> return ret;
> }
>
> -static struct ctl_table user_event_sysctls[] = {
> +static const struct ctl_table user_event_sysctls[] = {
> {
> .procname = "user_events_max",
> .data = &max_user_events,
Acked-by: Steven Rostedt (Google) # for kernel/trace/
-- Steve
On Thu, 5 Dec 2024 09:06:43 -0700
Shuah Khan wrote:
> I applied this to linux-kselftest fixes - will send it up for rc2 or rc3
Thanks Shuah,
-- Steve
On Tue, 3 Dec 2024 18:01:06 -0700
Shuah Khan wrote:
> On 12/2/24 12:41, Steven Rostedt wrote:
> > On Sat, 30 Nov 2024 01:56:21 +0530
> > Hari Bathini wrote:
> >
> >> In 'NOFENTRY_ARGS' test case for syntax check, any offset X of
> >> `vfs_
; configuration (see arch_kprobe_on_func_entry() for implementation
> details). So, use `vfs_read+20` to accommodate that scenario too.
>
> Suggested-by: Masami Hiramatsu
> Signed-off-by: Hari Bathini
Acked-by: Steven Rostedt (Google)
Shuah,
Can you take this through your tree?
Thanks,
On Wed, 23 Oct 2024 19:27:03 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Hi,
>
> This is an updated version of execmem ROX caches.
>
FYI, I booted a kernel before and after applying these patches with my
change:
https://lore.kernel.org/20241017113105.1edfa...@gandal
On Wed, 6 Nov 2024 14:04:14 +1100
Stephen Rothwell wrote:
> Hi all,
>
> After merging the ftrace tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/ftrace.h:23,
> from include/linux/kvm_host.h:32,
>
On Mon, 4 Nov 2024 04:36:15 -0600
Segher Boessenkool wrote:
> > >>Querying for function arguments is supported on kprobes only at function
> > >>entry. This is a negative test case where the offset is intentionally
> > >>set beyond function entry while querying for function arguments.
> > >>I gue
On Thu, 17 Oct 2024 14:25:05 +0300
Mike Rapoport wrote:
> With this series the module text is allocated as ROX at the first place, so
> the modifications ftrace does to module text have to either use text poking
> even before complete_formation() or deal with a writable copy like I did
> for relo
On Wed, 16 Oct 2024 17:01:28 -0400
Steven Rostedt wrote:
> If this is only needed for module load, can we at least still use the
> text_poke_early() at boot up?
>
> if (ftrace_poke_late) {
> text_poke_queue((void *)ip, new_code, MCOUNT_INSN_SIZE, NULL);
&g
On Wed, 16 Oct 2024 15:24:22 +0300
Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 8da0e66ca22d..b498897b213c 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -118,10 +118,13 @@ ftrace_modify_code_direct(unsigned long ip
On Fri, 11 Oct 2024 11:26:10 +0100
Catalin Marinas wrote:
> On Thu, Oct 10, 2024 at 08:21:14PM -0400, Steven Rostedt wrote:
> > diff --git a/arch/arm64/include/asm/ftrace.h
> > b/arch/arm64/include/asm/ftrace.h
> > index bbb69c7751b9..5ccff4de7f09 100644
> > -
From: Steven Rostedt
Most architectures use pt_regs within ftrace_regs making a lot of the
accessor functions just calls to the pt_regs internally. Instead of
duplication this effort, use a HAVE_ARCH_FTRACE_REGS for architectures
that have their own ftrace_regs that is not based on pt_regs and
]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/lin
Loongarch maintainers, please note the below comments!
On Tue, 08 Oct 2024 19:05:29 -0400
Steven Rostedt wrote:
> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
> index bbb69c7751b9..5ccff4de7f09 100644
> --- a/arch/arm64/include/asm/ftrace.h
>
On Wed, 9 Oct 2024 13:47:23 +0900
Masami Hiramatsu (Google) wrote:
> > --- /dev/null
> > +++ b/include/linux/ftrace_regs.h
> > @@ -0,0 +1,36 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _LINUX_FTRACE_TYPES_H
> > +#define _LINUX_FTRACE_TYPES_H
> Is
From: Steven Rostedt
ftrace_regs was created to hold registers that store information to save
function parameters, return value and stack. Since it is a subset of
pt_regs, it should only be used by its accessor functions. But because
pt_regs can easily be taken from ftrace_regs (on most archs
From: Steven Rostedt
Most architectures use pt_regs within ftrace_regs making a lot of the
accessor functions just calls to the pt_regs internally. Instead of
duplication this effort, use a HAVE_ARCH_FTRACE_REGS for architectures
that have their own ftrace_regs that is not based on pt_regs and
() and made it a static inline function
- Added a second patch that consolidates a lot of the duplicate code
when an architecture has pt_regs embedded in the ftrace_regs.
Steven Rostedt (2):
ftrace: Make ftrace_regs abstract from direct use
ftrace: Consolidate ftrace_regs accessor
On Wed, 9 Oct 2024 07:41:40 +0900
Masami Hiramatsu (Google) wrote:
> Hi Steve,
>
> > diff --git a/include/asm-generic/ftrace.h b/include/asm-generic/ftrace.h
> > index 3a23028d69d2..ba7b7d6e55d6 100644
> > --- a/include/asm-generic/ftrace.h
> > +++ b/include/asm-generic/ftrace.h
> > @@ -10,4 +1
On Tue, 8 Oct 2024 08:24:22 +0200
Christophe Leroy wrote:
> >> +
> >> +struct ftrace_regs;
> >> +#define arch_ftrace_regs(fregs) ((struct __arch_ftrace_regs *)(fregs))
> >> +
> >
> > I just realized I can simplify it with:
> >
> > #define arch_ftrace_get_regs(fregs) ({ &arch_ftrace_regs(fregs
On Tue, 8 Oct 2024 16:58:52 +0200
Heiko Carstens wrote:
> On Mon, Oct 07, 2024 at 08:54:58PM -0400, Steven Rostedt wrote:
> > On Mon, 7 Oct 2024 20:47:43 -0400
> > Steven Rostedt wrote:
> > #define arch_ftrace_get_regs(fregs) ({ &arch_ftrace_regs(fregs)->regs;
On Mon, 7 Oct 2024 20:47:43 -0400
Steven Rostedt wrote:
> +#ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
> +struct __arch_ftrace_regs {
> + struct pt_regs regs;
> +};
> +
> +#define arch_ftrace_get_regs(fregs) \
> + ({ str
From: Steven Rostedt
ftrace_regs was created to hold registers that store information to save
function parameters, return value and stack. Since it is a subset of
pt_regs, it should only be used by its accessor functions. But because
pt_regs can easily be taken from ftrace_regs (on most archs
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 __
1 - 100 of 636 matches
Mail list logo
