[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250917233818.71678d0164a6fc2d11fa6e38@kernel.org>
Date: Wed, 17 Sep 2025 23:38:18 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Peter Zijlstra
<peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, x86@...nel.org,
Jinchao Wang <wangjinchao600@...il.com>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
"H . Peter Anvin" <hpa@...or.com>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Ian Rogers <irogers@...gle.com>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v4 1/8] tracing: wprobe: Add watchpoint probe event
based on hardware breakpoint
Hi Randy,
On Sun, 14 Sep 2025 17:14:37 -0700
Randy Dunlap <rdunlap@...radead.org> wrote:
> > + w:[GRP/][EVENT] SPEC [FETCHARGS] : Probe on data access
> > +
> > + GRP : Group name for wprobe. If omitted, use "wprobes" for it.
> > + EVENT : Event name for wprobe. If omitted, an event name is
> > + generated based on the address or symbol.
> > + SPEC : Breakpoint specification.
> > + [r|w|rw]@<ADDRESS|SYMBOL[+|-OFFS]>[:LENGTH]
> > +
> > + r|w|rw : Access type, r for read, w for write, and rw for both.
> > + Use rw if omitted.
>
> Default is rw if omitted.
OK.
>
> > + ADDRESS : Address to trace (hexadecimal).
> > + SYMBOL : Symbol name to trace.
> > + LENGTH : Length of the data to trace in bytes. (1, 2, 4, or 8)
> > +
> > + FETCHARGS : Arguments. Each probe can have up to 128 args.
> > + $addr : Fetch the accessing address.
> > + @ADDR : Fetch memory at ADDR (ADDR should be in kernel)
> > + @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
> > + +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*1)(\*2)
> > + \IMM : Store an immediate value to the argument.
> > + NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
> > + FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
> > + (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types
> > + (x8/x16/x32/x64), "char", "string", "ustring", "symbol", "symstr"
> > + and bitfield are supported.
> > +
> > + (\*1) this is useful for fetching a field of data structures.
> > + (\*2) "u" means user-space dereference.
> > +
> > +For the details of TYPE, see :ref:`kprobetrace documentation <kprobetrace_types>`.
> > +
> > +Usage examples
> > +--------------
> > +Here is an example to add a wprobe event on a variable `jiffies`.
> > +::
> > +
> > + # echo 'w:my_jiffies w@...fies' >> dynamic_events
> > + # cat dynamic_events
> > + w:wprobes/my_jiffies w@...fies
> > + # echo 1 > events/wprobes/enable
> > + # cat trace | head
Note, I also found this is not head, but combined with tail,
e.g. `cat trace | head -n 15 | tail -n 5`
> > + # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
> > + # | | | ||||| | |
> > + <idle>-0 [000] d.Z1. 717.026259: my_jiffies: (tick_do_update_jiffies64+0xbe/0x130)
> > + <idle>-0 [000] d.Z1. 717.026373: my_jiffies: (tick_do_update_jiffies64+0xbe/0x130)
> > +
> > +You can see the code which writes to `jiffies` is `do_timer()`.
>
> I'm having trouble getting from tick_do_update_jiffies64+0xbe/0x130,
> which I expect is
> jiffies_64 += ticks;
> in that function, over to do_timer(), which also updates jiffies_64,
> but is not called by tick_do_update_jiffies64(). AFAICT, there are
> no calls to do_timer() in the file (kernel/time/tick-sched.c).
>
> Can you explain, please?
Hmm, in my code base
static void tick_do_update_jiffies64(ktime_t now)
{
...
} else {
last_jiffies_update = ktime_add_ns(last_jiffies_update,
TICK_NSEC);
}
/* Advance jiffies to complete the 'jiffies_seq' protected job */
jiffies_64 += ticks;
...
So this function seems correctly update the jiffies_64.
If you ask about where it comes from, I can also enable stacktrace on
that event. (echo 1 >> options/stacktrace)
cat-124 [005] d.Z1. 537.689753: my_jiffies: (tick_do_update_jiffies64+0xbe/0x130)
cat-124 [005] d.Z1. 537.689762: <stack trace>
=> tick_do_update_jiffies64
=> tick_nohz_handler
=> __hrtimer_run_queues
=> hrtimer_interrupt
=> __sysvec_apic_timer_interrupt
=> sysvec_apic_timer_interrupt
=> asm_sysvec_apic_timer_interrupt
So it came from hrtimer_interrupt().
>
>
>
> > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > index d2c79da81e4f..dd8919386425 100644
> > --- a/kernel/trace/Kconfig
> > +++ b/kernel/trace/Kconfig
> > @@ -807,6 +807,20 @@ config EPROBE_EVENTS
> > convert the type of an event field. For example, turn an
> > address into a string.
> >
> > +config WPROBE_EVENTS
> > + bool "Enable wprobe-based dynamic events"
> > + depends on TRACING
> > + depends on HAVE_HW_BREAKPOINT
> > + select PROBE_EVENTS
> > + select DYNAMIC_EVENTS
> > + default y
>
> Wny default y?
No big reason. This is just a dynamic event and unless the super user
adds this event this does not work on the system. I can make it N so
developer can enable it when builds their kernel.
Thank you,
>
> > + help
> > + This allows the user to add watchpoint tracing events based on
> > + hardware breakpoints on the fly via the ftrace interface.
> > +
> > + Those events can be inserted wherever hardware breakpoints can be
> > + set, and record various register and memory values.
> > +
> > config BPF_EVENTS
> > depends on BPF_SYSCALL
> > depends on (KPROBE_EVENTS || UPROBE_EVENTS) && PERF_EVENTS
>
>
> thanks.
> --
> ~Randy
>
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists