* [PATCH v3 18/18] Documentation/kernel-parameters: Add trace_remote
From: Vincent Donnefort @ 2026-07-21 10:36 UTC (permalink / raw)
To: rostedt, mhiramat, linux-trace-kernel
Cc: mathieu.desnoyers, kernel-team, linux-kernel, Vincent Donnefort
In-Reply-To: <20260721103603.342266-1-vdonnefort@google.com>
The trace_remote parameter allows configuring e a trace remote on
registration. The syntax is similar to trace_instance.
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22..3c1cf3025925 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7787,6 +7787,25 @@ Kernel parameters
See also Documentation/trace/ftrace.rst "trace options"
section.
+ trace_remote=[remote-info]
+ [FTRACE] Configure a trace remote instance at boot.
+ Format: <name>[^option1[^option2...]][,event1[,event2...]]
+
+ Supported options:
+
+ dump_on_panic - Enable dumping the trace buffer on
+ panic.
+ dmesg - Redirect tracing output to dmesg.
+ buf_size=<size> - Set the trace buffer size (e.g. 2M).
+ poll=<ms> - Set the trace remote polling interval
+ in milliseconds.
+
+ Events are a comma-separated list of events to enable.
+ If events are specified, tracing is automatically enabled.
+
+ Multiple remotes can be configured by specifying this
+ parameter multiple times.
+
trace_trigger=[trigger-list]
[FTRACE] Add an event trigger on specific events.
Set a trigger on top of a specific event, with an optional
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* Re: [PATCH v1 06/11] rcu: Enable RCU callbacks to benefit from expedited grace periods
From: Frederic Weisbecker @ 2026-07-21 12:06 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Puranjay Mohan, rcu, linux-kernel, linux-trace-kernel,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <cf1a3ffc-ed2a-41f4-bfd2-cbeab9d06861@paulmck-laptop>
Le Mon, Jul 20, 2026 at 09:55:42AM -0700, Paul E. McKenney a écrit :
> On Mon, Jul 20, 2026 at 04:22:33PM +0200, Frederic Weisbecker wrote:
> > Le Tue, Jul 14, 2026 at 11:48:08AM -0700, Paul E. McKenney a écrit :
> > > > I have similar concerns about the three smp_mb() in
> > > > get_state_synchronize_rcu_full(). It could be just two (rcu_seq_snap()
> > > > has a barrier that could be just one). Not sure if that matters but,
> > > > just wanted to point that.
> > >
> > > We need the one at the beginning of get_state_synchronize_rcu_full(),
> > > but from what I can see, not the ones in the calls to rcu_seq_snap().
> > > I blame laziness. We could make an rcu_seq_snap_no_ordering() that
> > > didn't have the smp_mb(), but I didn't believe that the overhead would
> > > be visible at the system level.
> >
> > It isn't so much about performance than being clear about ordering
> > expectations. Though we could argue that grace period polling can be
> > about performance.
> >
> > But in general rcu_seq_snap() advertizes:
> >
> > READ seq
> > smp_mb() /* Above access must not bleed into critical section. */
> >
> > This doesn't tell much. Which critical section? That's not used on
> > read side.
>
> Fair question!
>
> And the answer is "any critical section that might later be executed by
> the current task."
But why does it matter, what could go wrong for example?
>
> Would it help if I made that comment read as follows, separately from
> Puranjay's series?
>
> // The above access must not bleed into any later RCU read-side
> // critical section executed by the current task.
>
> Thanx, Paul
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption
From: Jinchao Wang @ 2026-07-21 12:36 UTC (permalink / raw)
To: Masami Hiramatsu (Google), Borislav Petkov
Cc: Dave Hansen, Andrew Morton, Peter Zijlstra, Thomas Gleixner,
Steven Rostedt, Ingo Molnar, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc
In-Reply-To: <20260720232442.3e6b0e70c6939541b8362e05@kernel.org>
On 7/20/2026 10:24 AM, Masami Hiramatsu (Google) wrote:
> On Fri, 17 Jul 2026 11:10:04 -0700
> Borislav Petkov <bp@alien8.de> wrote:
>> Looks to me like folks need to sit down and agree on strategy first.
>
> Yeah, I need to talk with Jinchao.
>
> Like kprobe, wprobe itself integrates watchpoint functionality into
> the tracing subsystem. Jinchao, I would like to ask you to redesign
> the kwatch tool based on fprobe and wprobe events in user space?
> I think that could reduce redundant efforts on the similar feature.
>
> Using fprobe entry and exit event trigger, we can make a Function-
> scoped watch window. Also, since fprobe and wprobe are having BTF
> typecast support, you can access to the members of data structures
> more naturally.
>
> If you are interested, I would be open to having you handle the
> development of the necessary features for wprobe.
>
> Thank you,
>
Thank you, Boris and Masami.
Boris is right that we should agree on the overall strategy before
moving either series forward, especially since they share the low-level
HWBP work. Masami is also right that fprobe and wprobe provide a more
appropriate foundation than introducing KWatch as another standalone
debugging tool.
After reconsidering the design, I will stop the standalone KWatch
series. Instead, I would like to work with Masami on extending wprobe
to support the function-scoped dynamic-watchpoint use cases that
motivated KWatch.
Masami, thank you for being open to having me develop the necessary
wprobe features. I am interested in taking that direction.
---
Thanks,
Jinchao
^ permalink raw reply
* Re: [PATCH v1 09/11] rcu: Detect expedited grace period completion in rcu_pending()
From: Frederic Weisbecker @ 2026-07-21 12:45 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-10-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:51AM -0700, Puranjay Mohan a écrit :
> rcu_pending() decides whether rcu_core() should run on the current CPU's
> timer tick. It does not account for expedited grace periods: after an
> expedited GP completes, a non-offloaded CPU's callbacks remain in
> RCU_WAIT_TAIL (not yet advanced to RCU_DONE_TAIL) and rcu_core() is
> never invoked to advance them.
>
> Detect that case via rcu_segcblist_nextgp() combined with a new
> memory-ordering-free poll variant,
> poll_state_synchronize_rcu_full_unordered(). This keeps rcu_pending()
> cheap: it runs on every tick that has pending callbacks, so it must
> not pay for the two memory barriers in
> poll_state_synchronize_rcu_full(). The check is only a hint to run
> rcu_core(); the ordered re-check and the actual callback advancement
> happen there.
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption
From: Jinchao Wang @ 2026-07-21 12:48 UTC (permalink / raw)
To: Dave Hansen, Andrew Morton, Peter Zijlstra, Thomas Gleixner,
Steven Rostedt, Masami Hiramatsu
Cc: Ingo Molnar, Borislav Petkov, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc
In-Reply-To: <91f3486b-3b85-4b43-b099-0a5325643352@intel.com>
On 7/17/2026 9:41 AM, Dave Hansen wrote:
> On 7/17/26 05:50, Jinchao Wang wrote:
>> 24 files changed, 2115 insertions(+), 63 deletions(-)
> Reading this, I wonder how many kernel debugging features we need. I
> don't even think we have a centralized list of them. They all just live
> in their own silos.
>
> This one really seems like a super specialized tool. It has to be
> enabled at compile time and specifically aimed at a specific function.
>
> Maybe this should live off on the side for a while. If folks end up
> actually needing it, they can point their friendly LLM over to its tree.
Thanks, Dave.
I agree that adding another standalone in-kernel debugging facility of
this size is not the right direction.
The motivation was practical. I have encountered several silent memory
corruption bugs for which I wrote similar one-off instrumentation to
identify the writer. KWatch was an attempt to make that technique
reusable instead of rebuilding it for each bug, and to reduce the same
setup cost for other developers facing similar problems.
This approach proved useful for localizing the dummy_hcd corruption:
https://lore.kernel.org/all/20260714064829.172098-1-wangjinchao600@gmail.com/
It identified the copy that overwrote req->complete and recorded the
writer's call stack. So I believe the debugging use case is valid, but
it does not require a separate KWatch implementation.
As discussed in my reply to Masami and Boris, I will stop pursuing the
standalone KWatch series and work with Masami on implementing the
necessary scoped watchpoint features in wprobe/tracing instead.
Thanks,
Jinchao
^ permalink raw reply
* Re: [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption
From: Jinchao Wang @ 2026-07-21 13:25 UTC (permalink / raw)
To: Marco Elver
Cc: Andrew Morton, Peter Zijlstra, Thomas Gleixner, Steven Rostedt,
Masami Hiramatsu, Ingo Molnar, Borislav Petkov, Dave Hansen,
H . Peter Anvin, x86, Arnaldo Carvalho de Melo, Namhyung Kim,
Mark Rutland, Mathieu Desnoyers, David Hildenbrand,
Jonathan Corbet, Matthew Wilcox, Alan Stern, Randy Dunlap,
Alexander Potapenko, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc
In-Reply-To: <CANpmjNMpKXxk2KsZORakwwdOpDG=pRbtJKi7doBt7QmQwUKdgw@mail.gmail.com>
On 7/20/2026 11:26 AM, Marco Elver wrote:
> On Fri, 17 Jul 2026 at 14:50, Jinchao Wang <wangjinchao600@gmail.com> wrote:
>>
>> Motivation
>> ==========
>>
>> The hardest memory corruption bugs are the silent ones: a rogue writer
>> scribbles over a live object through a stale pointer or a race, and
>
Thanks, Marco. These are good points. My cover letter did not clearly
separate two different classes of bugs.
> The stale/dangling pointer (use-after-free) case is the main one you're after?
Not exclusively. KASAN already does a good job as a general
use-after-free detector. However, a stale-pointer write after the
storage has been recycled, which may no longer be reported by Generic
KASAN, is one of the cases that the scoped watchpoint can help
localize.
The broader target is silent corruption of a known live victim object,
including non-UAF cases such as an in-bounds racing write to an object
whose allocation is still live.
>> the victim crashes in a code path far away from the culprit. Any
>> single developer hits such a bug rarely, but across the kernel's code
>> base and install base they keep arriving, and each one is
>> disproportionately expensive to localize. The question to answer is
>> "who wrote to this object, and from where?", and it is hard to get at
>> with the existing tools:
>>
>> - The kernel's own reports - an oops on a clobbered pointer, a
>> BUG_ON, a list-corruption warning - fire at the victim's access,
>> not at the corrupting write.
>> - KASAN/KFENCE catch memory-safety violations: out-of-bounds
>> accesses and use-after-free. But they have a blind spot: a
>> corrupting write can be fully memory-safe - a *valid* pointer, in
>
> Language-semantically speaking, a use-after-free write to recycled
> memory (be it in heap or stack) is NOT memory-safe. The detectors may
> not always catch these (KASAN relies on quarantine for that to
> increase the chances, but yeah, not guaranteed..).
>
You are right that a stale-pointer write to recycled storage remains a
use-after-free, so "memory-safe" was the wrong term. What I meant was
that such a corrupting write may not be detected by Generic KASAN at
the point where it occurs. KWatch was intended to use a hardware
watchpoint to catch the write and report the actual writer and its call
stack.
>> bounds, to a live object, written just at the wrong time or to the
>> wrong place - and then they stay silent by design. And even for
>> the bugs they can catch, KASAN's rebuild, overhead and redzones
>> change timing and layout enough that racy corruption often no
>> longer reproduces.
>
> There's also tag-based KASAN (KASAN_SW_TAGS or KASAN_HW_TAGS), of
> which KASAN_SW_TAGS has an x86 version based on LAM (not yet merged
> though? see https://lwn.net/ml/all/cover.1773164688.git.m.wieczorretman@pm.me/).
>
> One property of tag-based schemes (and any other lock+key detection
> scheme) is that upon recycling some memory, the tag (or key) to that
> location changes, and any previous pointer that still has the old tag
> will fault. The caveat with current pointer-tagging schemes is that
> entropy is relatively low (4 bit tags).
Thanks for pointing this out. I agree that tag-based KASAN can detect a
recycled-storage UAF when the new allocation receives a different tag,
so it covers part of the intended use case.
There are still cases it cannot detect, such as an in-bounds corrupting
write to the same still-live allocation, or a recycled allocation which
reuses the same tag. Software tag-based KASAN also still instruments
memory accesses and can perturb a timing-sensitive bug enough that it
no longer reproduces; hardware tag checking reduces this overhead but
is not available everywhere.
The original goal of KWatch, which I now plan to pursue through wprobe,
was to provide a simple and targeted interface to hardware watchpoints.
It does not instrument every memory access system-wide, so it can have
lower overall overhead and less timing perturbation while identifying
the actual writer. I see this as complementary to KASAN rather than a
replacement for it.
Thanks,
Jinchao
^ permalink raw reply
* Re: [PATCH v4 09/13] verification/rvgen: Delete __parse_constraint()
From: Nam Cao @ 2026-07-21 14:12 UTC (permalink / raw)
To: Gabriele Monaco
Cc: Steven Rostedt, Wander Lairson Costa, linux-trace-kernel,
linux-kernel
In-Reply-To: <2b19681b46b6bb5b64f1686c1ffa642a7bcef2a0.camel@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> Right good point, this is the branch I'm going to use to to send a pull request
> to Steve:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/gmonaco/linux.git/commit/?h=for-steve
Nice!
> I don't have direct access to linux-next and I was planning to wait for my
> testing series to avoid sending Steve 2 pull requests in about a week. Unless
> there's something terribly wrong in that series, I think it's not going to take
> too long until they all land on next.
>
> What do you think?
I didn't know you can't include your tree in linux-next. That would be
nice. But well, it is still fine as is.
Nam
^ permalink raw reply
* Re: [PATCH v1 09/11] rcu: Detect expedited grace period completion in rcu_pending()
From: Paul E. McKenney @ 2026-07-21 14:32 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Puranjay Mohan, rcu, linux-kernel, linux-trace-kernel,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <al9p8MrcEdByrjfh@localhost.localdomain>
On Tue, Jul 21, 2026 at 02:45:36PM +0200, Frederic Weisbecker wrote:
> Le Wed, Jun 24, 2026 at 06:23:51AM -0700, Puranjay Mohan a écrit :
> > rcu_pending() decides whether rcu_core() should run on the current CPU's
> > timer tick. It does not account for expedited grace periods: after an
> > expedited GP completes, a non-offloaded CPU's callbacks remain in
> > RCU_WAIT_TAIL (not yet advanced to RCU_DONE_TAIL) and rcu_core() is
> > never invoked to advance them.
> >
> > Detect that case via rcu_segcblist_nextgp() combined with a new
> > memory-ordering-free poll variant,
> > poll_state_synchronize_rcu_full_unordered(). This keeps rcu_pending()
> > cheap: it runs on every tick that has pending callbacks, so it must
> > not pay for the two memory barriers in
> > poll_state_synchronize_rcu_full(). The check is only a hint to run
> > rcu_core(); the ordered re-check and the actual callback advancement
> > happen there.
> >
> > Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Thank you! I will apply this on my next rebase.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v1 10/11] rcu: Advance callbacks for expedited GP completion in rcu_core()
From: Frederic Weisbecker @ 2026-07-21 14:35 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-11-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:52AM -0700, Puranjay Mohan a écrit :
> Even when rcu_pending() triggers rcu_core(), the normal callback
> advancement path through note_gp_changes() -> __note_gp_changes() bails
> out when rdp->gp_seq == rnp->gp_seq (no normal GP change). Since
> expedited GPs do not update rnp->gp_seq, rcu_advance_cbs() is never
> called and callbacks remain stuck in RCU_WAIT_TAIL.
>
> Add a direct callback advancement block in rcu_core() that checks for GP
> completion via rcu_segcblist_nextgp() combined with
> poll_state_synchronize_rcu_full(). When detected, trylock rnp and call
> rcu_advance_cbs() to move completed callbacks to RCU_DONE_TAIL. Wake the
> GP kthread if rcu_advance_cbs() requests a new grace period.
>
> Uses trylock to avoid adding contention on rnp->lock. If the lock is
> contended, callbacks will be advanced on the next tick.
>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
> kernel/rcu/tree.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index b01d7bf6b57b1..f42e01ef479c4 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2891,6 +2891,23 @@ static __latent_entropy void rcu_core(void)
> /* Update RCU state based on any recent quiescent states. */
> rcu_check_quiescent_state(rdp);
>
> + /* Advance callbacks if an expedited GP has completed. */
> + if (!rcu_rdp_is_offloaded(rdp) && rcu_segcblist_is_enabled(&rdp->cblist)) {
> + struct rcu_gp_seq gp_state;
> +
> + if (rcu_segcblist_nextgp(&rdp->cblist, &gp_state) &&
> + poll_state_synchronize_rcu_full(&gp_state)) {
> + guard(irqsave)();
> + if (raw_spin_trylock_rcu_node(rnp)) {
> + bool needwake = rcu_advance_cbs(rnp, rdp);
> +
> + raw_spin_unlock_rcu_node(rnp);
> + if (needwake)
> + rcu_gp_kthread_wake();
> + }
> + }
> + }
Should that go as an improvement to note_gp_changes() instead?
Thanks.
> +
> /* No grace period and unregistered callbacks? */
> if (!rcu_gp_in_progress() &&
> rcu_segcblist_is_enabled(&rdp->cblist) && !rcu_rdp_is_offloaded(rdp)) {
> --
> 2.53.0-Meta
>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 10/11] rcu: Advance callbacks for expedited GP completion in rcu_core()
From: Puranjay Mohan @ 2026-07-21 15:06 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <al-DopVEIe2FvLnv@localhost.localdomain>
On Tue, Jul 21, 2026 at 3:35 PM Frederic Weisbecker <frederic@kernel.org> wrote:
>
> Le Wed, Jun 24, 2026 at 06:23:52AM -0700, Puranjay Mohan a écrit :
> > Even when rcu_pending() triggers rcu_core(), the normal callback
> > advancement path through note_gp_changes() -> __note_gp_changes() bails
> > out when rdp->gp_seq == rnp->gp_seq (no normal GP change). Since
> > expedited GPs do not update rnp->gp_seq, rcu_advance_cbs() is never
> > called and callbacks remain stuck in RCU_WAIT_TAIL.
> >
> > Add a direct callback advancement block in rcu_core() that checks for GP
> > completion via rcu_segcblist_nextgp() combined with
> > poll_state_synchronize_rcu_full(). When detected, trylock rnp and call
> > rcu_advance_cbs() to move completed callbacks to RCU_DONE_TAIL. Wake the
> > GP kthread if rcu_advance_cbs() requests a new grace period.
> >
> > Uses trylock to avoid adding contention on rnp->lock. If the lock is
> > contended, callbacks will be advanced on the next tick.
> >
> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> > Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> > ---
> > kernel/rcu/tree.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index b01d7bf6b57b1..f42e01ef479c4 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2891,6 +2891,23 @@ static __latent_entropy void rcu_core(void)
> > /* Update RCU state based on any recent quiescent states. */
> > rcu_check_quiescent_state(rdp);
> >
> > + /* Advance callbacks if an expedited GP has completed. */
> > + if (!rcu_rdp_is_offloaded(rdp) && rcu_segcblist_is_enabled(&rdp->cblist)) {
> > + struct rcu_gp_seq gp_state;
> > +
> > + if (rcu_segcblist_nextgp(&rdp->cblist, &gp_state) &&
> > + poll_state_synchronize_rcu_full(&gp_state)) {
> > + guard(irqsave)();
> > + if (raw_spin_trylock_rcu_node(rnp)) {
> > + bool needwake = rcu_advance_cbs(rnp, rdp);
> > +
> > + raw_spin_unlock_rcu_node(rnp);
> > + if (needwake)
> > + rcu_gp_kthread_wake();
> > + }
> > + }
> > + }
>
> Should that go as an improvement to note_gp_changes() instead?
note_gp_changes() only reconciles rdp->gp_seq against rnp->gp_seq, and
the expedited path never advances rnp->gp_seq. So the gap this closes
is exactly rdp->gp_seq == rnp->gp_seq, where note_gp_changes() and
__note_gp_changes() both short-circuit, the expedited completion isn't
visible there at all. It's detected from the cblist's stored gp_seq
(rcu_segcblist_nextgp()) confirmed with
poll_state_synchronize_rcu_full(), so hosting it in note_gp_changes()
would mean running that in the lockless preamble for every caller,
including the off-tick call_rcu_core() path. In rcu_core() it's
already gated by rcu_pending(), which does the barrier-free detection.
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] uprobes: Switch uretprobes_srcu to SRCU-fast-updown
From: Kumar Kartikeya Dwivedi @ 2026-07-21 19:44 UTC (permalink / raw)
To: Andrii Nakryiko, Puranjay Mohan, Peter Zijlstra, Ingo Molnar
Cc: Lai Jiangshan, Paul E. McKenney, Josh Triplett, Masami Hiramatsu,
Oleg Nesterov, Arnaldo Carvalho de Melo, Namhyung Kim,
Alexei Starovoitov, Andrii Nakryiko, Steven Rostedt,
Mathieu Desnoyers, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, rcu, linux-kernel,
linux-trace-kernel, linux-perf-users, bpf
In-Reply-To: <CAEf4BzaDSeUxeZmHjXRYXnXDZj8Obwd3rmOsfNygjcXJ0yy5bA@mail.gmail.com>
On Fri Jul 10, 2026 at 11:23 PM CEST, Andrii Nakryiko wrote:
> On Mon, Jul 6, 2026 at 10:28 AM Puranjay Mohan <puranjay@kernel.org> wrote:
>>
>> uretprobes_srcu currently uses normal SRCU, which issues
>> two smp_mb() per read lock/unlock pair. This overhead is
>> paid on every uretprobe hit.
>>
>> Switch to SRCU-fast-updown, which eliminates the per-reader
>> memory barriers by moving the ordering cost to the
>> grace-period side (synchronize_rcu() instead of smp_mb()).
>> This is acceptable because grace periods (uprobe
>> unregistration) are infrequent compared to reader-side
>> uretprobe hits.
>>
>> The updown flavor is required because the SRCU read lock is
>> taken in prepare_uretprobe() when a return instance is
>> created and is held until that return instance is finalized.
>> The traced thread returns to user space in between, so the
>> lock is inherently released in a different context from
>> where it was acquired: on the normal return path via
>> uprobe_handle_trampoline() -> hprobe_finalize(), or from
>> ri_timer() (expiry) or dup_utask() (fork) via
>> hprobe_expire(). srcu_down_read_fast() / srcu_up_read_fast()
>> are designed for this acquire-here / release-elsewhere
>> pattern and, unlike the same-context srcu_read_lock_fast()
>> variant, do not carry the lockdep read-side tracking that
>> would warn on it.
>>
>> The short, same-context SRCU sections in ri_timer() and
>> dup_utask() (which guard the uprobe against reuse across the
>> hprobe_expire() cmpxchg) instead use guard(srcu_fast_updown)
>> for proper lockdep coverage.
>>
>> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
>> ---
>> include/linux/uprobes.h | 5 +++--
>> kernel/events/uprobes.c | 29 +++++++++++++++++------------
>> 2 files changed, 20 insertions(+), 14 deletions(-)
>>
>
> Very straightforward replacement and will improve performance, thanks!
> LGTM. Peter or Mingo, I assume you guys will want to route this
> through your tip tree, right?
>
> Acked-by: Andrii Nakryiko <andrii@kernel.org>
>
Hi Peter, Ingo,
Gentle ping for this.
> [...]
^ permalink raw reply
* [PATCH] selftests/ftrace: allow relative paths in eprobe test
From: Martin Kaiser @ 2026-07-21 20:05 UTC (permalink / raw)
To: Masami Hiramatsu, Steven Rostedt, Shuah Khan
Cc: linux-kernel, linux-trace-kernel, linux-kselftest, oe-lkp, lkp,
Martin Kaiser, kernel test robot
The add/remove eprobe test installs an eprobe for the openat syscall,
runs ls and checks the filenames that were opened.
Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING
pointer") fixed access to some string fields in eprobes. This allows for
dereferencing more filenames. In some cases, the log now shows a file
with a relative path instead of "(fault)". A relative path makes the
test fail.
Relax the filename checks to fix the test. Allow shared libraries and
locale configs that use a relative path.
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202607151010.b68428e1-lkp@intel.com
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
.../selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
index c300eb020262..baceeca7ccdf 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_eprobe.tc
@@ -22,7 +22,8 @@ ls
echo 0 > events/eprobes/$EPROBE/enable
content=`grep '^ *ls-' trace | grep 'file='`
-nocontent=`grep '^ *ls-' trace | grep 'file=' | grep -v -e '"/' -e '"."' -e '(fault)' ` || true
+nocontent=`grep '^ *ls-' trace | grep 'file=' | \
+ grep -v -e '"/' -e '.so' -e 'locale' -e '"."' -e '(fault)'` || true
if [ -z "$content" ]; then
exit_fail
--
2.43.7
^ permalink raw reply related
* Re: [PATCH] x86/stacktrace: Mark arch_stack_walk() and unwinder functions notrace
From: Steven Rostedt @ 2026-07-21 20:32 UTC (permalink / raw)
To: Yuanhe Shu
Cc: Josh Poimboeuf, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin,
Masami Hiramatsu, linux-kernel, linux-trace-kernel, stable
In-Reply-To: <20260706105715.769ba488@gandalf.local.home>
On Mon, 6 Jul 2026 10:57:15 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 6 Jul 2026 17:54:45 +0800
> Yuanhe Shu <xiangzao@linux.alibaba.com> wrote:
>
> > When the function tracer's func_stack_trace option and the function graph
> > profiler (function_profile_enabled) are both active, a recursive ftrace
> > reentrance can occur, leading to a hard lockup. This was observed during
> > ftrace selftest (ftracetest-ktap) execution:
> >
> > watchdog: Watchdog detected hard LOCKUP on cpu 204
> > RIP: profile_graph_entry+0xa0/0x160
> > Call Trace:
> > function_graph_enter+0xc9/0x120
> > arch_ftrace_ops_list_func+0x112/0x230
> > ftrace_call+0x5/0x44
> > unwind_next_frame+0x5/0x870 <-- traced by ftrace
> > arch_stack_walk+0x88/0xf0
> > stack_trace_save+0x4b/0x70
> > __ftrace_trace_stack+0x12e/0x170
> > function_stack_trace_call+0x7c/0xa0
> > arch_ftrace_ops_list_func+0x112/0x230
> > ftrace_call+0x5/0x44
> > irqtime_account_irq+0x5/0xb0
> > __irq_exit_rcu+0x12/0xc0
> > ...
> >
> > The root cause is a recursive ftrace reentrance:
> > function_stack_trace_call() invokes __trace_stack() ->
> > arch_stack_walk() -> unwind_next_frame() to capture a backtrace.
> > Since the unwinder functions (__unwind_start(),
> > unwind_next_frame(), unwind_get_return_address(),
> > unwind_get_return_address_ptr()) are not marked notrace, the
> > function graph tracer instruments them, re-entering the ftrace
> > infrastructure from within an ftrace callback. This results in a
> > hard lockup with interrupts disabled, detected by the watchdog NMI.
>
> I'm fine with this change, but I'm wondering why the recursion protection
> didn't catch this. There may be a missing check somewhere. I'll ack this
> change, but I also want to add the check that would have prevented this
> lockup.
I tried to reproduce it, but it appears to be a case where things slow down
so much that it triggers a lockup when it's not really locked up, but is
moving so slow that the watchdog triggers.
The recursive protection *is* working, but it still allows one recursion to
take place (there's an unrelated reason for that). Thus what we have is
that every time the function profiler does a stack trace, the function
tracer recurses the unwind functions and it too does a stack trace. This
just slows things down a lot more.
With CONFIG_FTRACE_RECORD_RECURSION enabled, I get the following:
# echo 1 > /sys/kernel/tracing/function_profile_enabled
# trace-cmd start -p function -l 'unwind_*' --func-stack
# cat /sys/kernel/tracing/recursed_functions
__unwind_start+0x3c3/0x7e0: unwind_next_frame+0x4/0x2220
arch_stack_walk+0xb7/0x100: unwind_get_return_address+0x4/0xe0
Thus unwind_next_frame and unwind_get_return_address both had recursion
from just tracing functions that started with "unwind_". It would be much
worse if you traced more.
Since function stack tracing is known to cause slowdowns and is even
documented as possibly locking up the machine, this is *not* a fix nor
belongs in stable. But it is OK to be added in the next merge window.
x86 maintainers, feel free to take this with my ack, but you can remove the
fixes and stable tags.
-- Steve
^ permalink raw reply
* Re: [PATCH v3 1/2] soc: qcom: geni-se: trace: Add trace event support for GENI SE registers dump
From: Steven Rostedt @ 2026-07-21 20:52 UTC (permalink / raw)
To: Praveen Talari
Cc: Bjorn Andersson, Konrad Dybcio, Masami Hiramatsu,
Mathieu Desnoyers, Mark Brown, linux-kernel, linux-arm-msm,
linux-trace-kernel, linux-spi, Mukesh Kumar Savaliya
In-Reply-To: <20260715-add-tracepoints-for-se-reg-dump-v3-1-0f787f93badd@oss.qualcomm.com>
On Wed, 15 Jul 2026 10:50:47 +0530
Praveen Talari <praveen.talari@oss.qualcomm.com> wrote:
> + TP_fast_assign(__assign_str(geni_se_name);
> + __entry->geni_se_m_cmd0 = readl(se->base + SE_GENI_M_CMD0);
> + __entry->geni_se_m_irq_status = readl(se->base + SE_GENI_M_IRQ_STATUS);
> + __entry->geni_se_s_cmd0 = readl(se->base + SE_GENI_S_CMD0);
> + __entry->geni_se_s_irq_status = readl(se->base + SE_GENI_S_IRQ_STATUS);
> + __entry->geni_se_status = readl(se->base + SE_GENI_STATUS);
> + __entry->geni_se_ios = readl(se->base + SE_GENI_IOS);
> + __entry->geni_se_m_cmd_ctrl = readl(se->base + SE_GENI_M_CMD_CTRL_REG);
> + __entry->geni_se_m_cmd_err = readl(se->base + M_CMD_ERR_STATUS);
> + __entry->geni_se_m_fw_err = readl(se->base + M_FW_ERR_STATUS);
> + __entry->geni_se_tx_fifo_status = readl(se->base + SE_GENI_TX_FIFO_STATUS);
> + __entry->geni_se_rx_fifo_status = readl(se->base + SE_GENI_RX_FIFO_STATUS);
> + __entry->geni_se_tx_watermark = readl(se->base + SE_GENI_TX_WATERMARK_REG);
> + __entry->geni_se_rx_watermark = readl(se->base + SE_GENI_RX_WATERMARK_REG);
> + __entry->geni_se_rx_watermark_rfr = readl(se->base + SE_GENI_RX_RFR_WATERMARK_REG);
> + __entry->geni_se_m_gp_length = readl(se->base + SE_GENI_M_GP_LENGTH);
> + __entry->geni_se_s_gp_length = readl(se->base + SE_GENI_S_GP_LENGTH);
> + __entry->geni_se_dma_tx_irq = readl(se->base + SE_DMA_TX_IRQ_STAT);
> + __entry->geni_se_dma_rx_irq = readl(se->base + SE_DMA_RX_IRQ_STAT);
> + __entry->geni_se_dma_tx_irq_en = readl(se->base + SE_DMA_TX_IRQ_EN);
> + __entry->geni_se_dma_rx_irq_en = readl(se->base + SE_DMA_RX_IRQ_EN);
> + __entry->geni_se_dma_rx_len = readl(se->base + SE_DMA_RX_LEN);
> + __entry->geni_se_dma_rx_len_in = readl(se->base + SE_DMA_RX_LEN_IN);
> + __entry->geni_se_dma_tx_len = readl(se->base + SE_DMA_TX_LEN);
> + __entry->geni_se_dma_tx_len_in = readl(se->base + SE_DMA_TX_LEN_IN);
> + __entry->geni_se_dma_tx_ptr_l = readl(se->base + SE_DMA_TX_PTR_L);
> + __entry->geni_se_dma_tx_ptr_h = readl(se->base + SE_DMA_TX_PTR_H);
> + __entry->geni_se_dma_rx_ptr_l = readl(se->base + SE_DMA_RX_PTR_L);
> + __entry->geni_se_dma_rx_ptr_h = readl(se->base + SE_DMA_RX_PTR_H);
> + __entry->geni_se_dma_tx_attr = readl(se->base + SE_DMA_TX_ATTR);
> + __entry->geni_se_dma_tx_max_burst = readl(se->base + SE_DMA_TX_MAX_BURST);
> + __entry->geni_se_dma_rx_attr = readl(se->base + SE_DMA_RX_ATTR);
> + __entry->geni_se_dma_rx_max_burst = readl(se->base + SE_DMA_RX_MAX_BURST);
> + __entry->geni_se_dma_if_en = readl(se->base + SE_DMA_IF_EN);
> + __entry->geni_se_dma_if_en_ro = readl(se->base + DMA_IF_EN_RO);
> + __entry->geni_se_dma_general_cfg = readl(se->base + DMA_GENERAL_CFG);
> + __entry->geni_se_dma_qsb_trans_cfg = readl(se->base + SE_DMA_QSB_TRANS_CFG);
> + __entry->geni_se_dma_dbg = readl(se->base + SE_DMA_DEBUG_REG0);
> + __entry->geni_se_m_irq_en = readl(se->base + SE_GENI_M_IRQ_EN);
> + __entry->geni_se_s_irq_en = readl(se->base + SE_GENI_S_IRQ_EN);
> + __entry->geni_se_gsi_event_en = readl(se->base + SE_GSI_EVENT_EN);
> + __entry->geni_se_irq_en = readl(se->base + SE_IRQ_EN);
> + __entry->geni_se_ser_m_clk_cfg = readl(se->base + GENI_SER_M_CLK_CFG);
> + __entry->geni_se_ser_s_clk_cfg = readl(se->base + GENI_SER_S_CLK_CFG);
> + __entry->geni_se_general_cfg = readl(se->base + GENI_GENERAL_CFG);
> + __entry->geni_se_output_ctrl = readl(se->base + GENI_OUTPUT_CTRL);
> + __entry->geni_se_clk_ctrl_ro = readl(se->base + GENI_CLK_CTRL_RO);
> + __entry->geni_se_fifo_if_disable = readl(se->base + GENI_IF_DISABLE_RO);
> + __entry->geni_se_fw_multilock_msa = readl(se->base + GENI_FW_MULTILOCK_MSA_RO);
> + __entry->geni_se_clk_sel = readl(se->base + SE_GENI_CLK_SEL);
> + ),
> +
I think this is the first time I've seen a trace event read IO directly.
Hmm, will this have any side effects?
If not, I have no problem with this:
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [RFC] tracing: Try user copies with page faults disabled first
From: Steven Rostedt @ 2026-07-21 21:05 UTC (permalink / raw)
To: Usama Arif
Cc: linux-kernel, linux-trace-kernel, mathieu.desnoyers, mhiramat,
leitao
In-Reply-To: <20260717173758.3644427-1-usama.arif@linux.dev>
On Fri, 17 Jul 2026 10:37:57 -0700
Usama Arif <usama.arif@linux.dev> wrote:
> I think the actual problem might be:
> https://lore.kernel.org/all/20260717173252.3431565-1-usama.arif@linux.dev/
Ah probably. Thanks for finding and fixing it. I'll add that one to my
queue and set this patch to "superseded".
-- Steve
^ permalink raw reply
* Re: [PATCH v1 v1 2/7] ntfs3: add namei tracepoints
From: Steven Rostedt @ 2026-07-21 21:09 UTC (permalink / raw)
To: Baolin Liu
Cc: almaz.alexandrovich, mhiramat, mathieu.desnoyers, linux-kernel,
ntfs3, linux-trace-kernel, liubaolin12138, Baolin Liu
In-Reply-To: <20260717032248.3318208-3-liubaolin12138@163.com>
On Fri, 17 Jul 2026 11:22:43 +0800
Baolin Liu <liubaolin12138@163.com> wrote:
> +TRACE_EVENT(ntfs3_lookup,
> + TP_PROTO(struct inode *dir, struct dentry *dentry),
> + TP_ARGS(dir, dentry),
> + TP_STRUCT__entry(
> + __field(dev_t, dev)
> + __field(unsigned long, parent_ino)
> + __string(name, dentry->d_name.name)
> + __field(unsigned int, name_len)
> + ),
> + TP_fast_assign(
> + __entry->dev = dir->i_sb->s_dev;
> + __entry->parent_ino = dir->i_ino;
> + __assign_str(name);
> + __entry->name_len = dentry->d_name.len;
Is dentry->d_name.len not equal to strlen(dentry->d_name.name) + 1 ?
-- Steve
> + ),
> + TP_printk("dev=(%d,%d) parent=%lu name=%s len=%u",
> + MAJOR(__entry->dev), MINOR(__entry->dev),
> + __entry->parent_ino, __get_str(name),
> + __entry->name_len)
> +);
^ permalink raw reply
* Re: [RFC PATCH 6/7] mm: add tracepoints and vmstat counters for async teardown
From: Steven Rostedt @ 2026-07-21 21:17 UTC (permalink / raw)
To: Aditya Sharma
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, David Rientjes, Shakeel Butt,
Jonathan Corbet, Shuah Khan, Masami Hiramatsu, Mathieu Desnoyers,
Kees Cook, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, linux-mm, linux-doc,
linux-trace-kernel, linux-kernel, imbrenda
In-Reply-To: <20260719185409.409685-7-adi.sharma@zohomail.in>
On Mon, 20 Jul 2026 00:24:08 +0530
Aditya Sharma <adi.sharma@zohomail.in> wrote:
> diff --git a/include/trace/events/mm_reaper.h b/include/trace/events/mm_reaper.h
> new file mode 100644
> index 000000000..315bced7c
> --- /dev/null
> +++ b/include/trace/events/mm_reaper.h
> @@ -0,0 +1,73 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM mm_reaper
> +
> +#if !defined(_TRACE_MM_REAPER_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_MM_REAPER_H
> +
> +#include <linux/tracepoint.h>
> +#include <linux/sched.h>
> +#include <linux/topology.h>
> +
> +TRACE_EVENT(mm_async_teardown_queue,
> +
> + TP_PROTO(struct mm_struct *mm, unsigned long rss),
> +
> + TP_ARGS(mm, rss),
> +
> + TP_STRUCT__entry(
> + __field(struct mm_struct *, mm)
> + __field(int, pid)
> + __array(char, comm, TASK_COMM_LEN)
There's an effort to make comm size more dynamic and we want to prevent more
memcpy of the comm based on TASK_COMM_LEN. Please change the above to:
__string(comm, comm);
> + __field(unsigned long, rss)
> + __field(int, node)
> + ),
> +
> + TP_fast_assign(
> + __entry->mm = mm;
> + __entry->pid = current->pid;
> + memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
And this to:
__assign_str(comm);
> + __entry->rss = rss;
> + __entry->node = numa_node_id();
> + ),
> +
> + TP_printk("mm=%p pid=%d comm=%s rss=%lukB node=%d",
> + __entry->mm,
> + __entry->pid,
> + __entry->comm,
and this to:
__get_str(comm),
Thanks,
-- Steve
> + __entry->rss << (PAGE_SHIFT - 10),
> + __entry->node
> + )
> +);
> +
^ permalink raw reply
* Re: [PATCH] tracing/mmiotrace: fix resource leak on trace_pipe close
From: Steven Rostedt @ 2026-07-22 0:38 UTC (permalink / raw)
To: deepakraog
Cc: Masami Hiramatsu, Pekka Paalanen, Mathieu Desnoyers, linux-kernel,
nouveau, linux-trace-kernel
In-Reply-To: <20260715143604.14481-1-gaikwad.dcg@gmail.com>
On Wed, 15 Jul 2026 20:06:04 +0530
deepakraog <gaikwad.dcg@gmail.com> wrote:
> mmio_pipe_open() allocates a header_iter and takes a pci_dev reference
> when trace_pipe is opened. mmio_close() frees them, but it was only
> wired to the tracer's .close callback.
Were you able to trigger a kmemleak?
>
> tracing_release_pipe() invokes .pipe_close, not .close, when the
> trace_pipe file is released. As a result, closing trace_pipe with the
> mmiotrace tracer active leaked the header_iter allocation and left a
> stale pci_dev reference.
It would be good if you showed how a leak can happen, as the mmio_read()
does clean up the descriptor, making the above statement incorrect.
>
> Set .pipe_close to mmio_close, matching how function_graph wires both
> callbacks to the same handler.
>
The mmio_read() will free up the descriptor if you read the trace_pipe file
until it blocks. But reading part of it may trigger the leak. Such as:
# head -n 1 /sys/kernel/tracing/trace_pipe
head: /sys/kernel/tracing/trace_pipe: cannot seek to relative offset 0: Illegal seek
VERSION 20070824
and running that over and over again will produce a leak caught by kmemleak.
I'll update the change log.
-- Steve
^ permalink raw reply
* [PATCH] tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev
From: Steven Rostedt @ 2026-07-22 1:11 UTC (permalink / raw)
To: LKML, Linux Trace Kernel; +Cc: Masami Hiramatsu, Mathieu Desnoyers
From: Steven Rostedt <rostedt@goodmis.org>
If the mmio_pipe_open() fails to find a PCI device, the hiter->dev
will be assigned to NULL. The mmiotrace read() function dereferences the
hiter->dev if hiter exists.
Change the test of the read to not only check hiter being NULL, but also
the hiter->dev before dereferencing it.
Cc: stable@vger.kernel.org
Fixes: f984b51e0779 ("ftrace: add mmiotrace plugin")
Reported-by: Sashiko
Link: https://sashiko.dev/#/patchset/20260715143604.14481-1-gaikwad.dcg%40gmail.com
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace_mmiotrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index 20812e7f911f..b88b8d9923ad 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -145,7 +145,7 @@ static ssize_t mmio_read(struct trace_iterator *iter, struct file *filp,
goto print_out;
}
- if (!hiter)
+ if (!hiter || !hiter->dev)
return 0;
mmio_print_pcidev(s, hiter->dev);
--
2.53.0
^ permalink raw reply related
* [PATCH] tracing: Do not clean up hiter in mmiotrace read function
From: Steven Rostedt @ 2026-07-22 1:20 UTC (permalink / raw)
To: LKML, Linux Trace Kernel; +Cc: Masami Hiramatsu, Mathieu Desnoyers
From: Steven Rostedt <rostedt@goodmis.org>
When the mmiotrace trace was first created, it allocated a descriptor in
its pipe_open() method. Since there was no pipe_close() method when it was
created (in May of 2008, and pipe_close() was added in December of 2009),
it cleaned up the allocated descriptors in the read.
Now that the clean up is in the pipe_close() method that now exists,
remove the clean up from the read as it is no longer needed.
Also simplify the code by inverting the early exit conditional into a
conditional to perform the logic and get rid of the goto.
Link: https://lore.kernel.org/all/20260715143604.14481-1-gaikwad.dcg@gmail.com/
Link: https://lore.kernel.org/all/20260721211143.36dbd559@gandalf.local.home/
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace_mmiotrace.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index b88b8d9923ad..ba604c22d2d2 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -142,21 +142,13 @@ static ssize_t mmio_read(struct trace_iterator *iter, struct file *filp,
if (!overrun_detected)
pr_warn("mmiotrace has lost events\n");
overrun_detected = true;
- goto print_out;
}
- if (!hiter || !hiter->dev)
- return 0;
-
- mmio_print_pcidev(s, hiter->dev);
- hiter->dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, hiter->dev);
-
- if (!hiter->dev) {
- destroy_header_iter(hiter);
- iter->private = NULL;
+ if (hiter && hiter->dev) {
+ mmio_print_pcidev(s, hiter->dev);
+ hiter->dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, hiter->dev);
}
-print_out:
ret = trace_seq_to_user(s, ubuf, cnt);
return (ret == -EBUSY) ? 0 : ret;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 4/4] rv/rtapp: Add wakeup monitor
From: Chao Liu @ 2026-07-22 4:45 UTC (permalink / raw)
To: Nam Cao
Cc: Gabriele Monaco, Steven Rostedt, linux-trace-kernel, linux-doc,
linux-kernel
In-Reply-To: <ba5658fa13e49ada466b84a2c211f233037180b5.1781852967.git.namcao@linutronix.de>
Hi Nam,
I've been looking into the RV subsystem, and while reading this patch
I noticed a small inconsistency.
On Fri, Jun 19, 2026 at 09:21:22AM +0800, Nam Cao wrote:
> Add a wakeup monitor to detect a lower-priority task waking up a
> higher-priority task.
>
> The rtapp/sleep monitor already detects this. However, that monitor
> triggers an error in the context of the wakee task and user only gets
> the stacktrace of that task. It is also extremely useful to get the
> stacktrace of the waker task, which this monitor offers. In other
> words, this monitor complements the rtapp/sleep monitor.
>
> Signed-off-by: Nam Cao <namcao@linutronix.de>
> ---
[...]
> +Monitor wakeup
> +++++++++++++++
> +
> +The `wakeup` monitor reports real-time threads being woken by lower-priority threads,
> +which is a hint of priority inversion. Its specification is::
> +
> + RULE = always (((RT and USER_THREAD) imply
> + (not (WOKEN_BY_LOWER_PRIO or WOKEN_BY_SOFTIRQ)) or ALLOWLIST))
> +
> + ALLOWLIST = BLOCK_ON_RT_MUTEX
> + or FUTEX_LOCK_PI
> +
[...]
> +static void handle_sched_waking(void *data, struct task_struct *task)
> +{
> + if (in_task()) {
> + if (current->prio > task->prio)
> + ltl_atom_pulse(task, LTL_WOKEN_BY_LOWER_PRIO, true);
The implementation also reports wakeups from softirq context through
WOKEN_BY_SOFTIRQ:
> + } else if (in_serving_softirq()) {
> + ltl_atom_pulse(task, LTL_WOKEN_BY_SOFTIRQ, true);
> + }
Should this description mention softirq wakeups as well?
The Kconfig help text, struct rv_monitor's .description, and
MODULE_DESCRIPTION() seem to have the same omission.
I also have a small follow-up documentation patch based on this series,
which I plan to send as an RFC shortly.
Thanks,
Chao
^ permalink raw reply
* [RFC PATCH] Documentation/rv: Explain epoll and aborted sleeps
From: Chao Liu @ 2026-07-22 4:57 UTC (permalink / raw)
To: Nam Cao, Steven Rostedt, Gabriele Monaco, Jonathan Corbet
Cc: lianux.mm, lianux.wang, Shuah Khan, linux-trace-kernel, linux-doc,
linux-kernel, Chao Liu
The rtapp sleep monitor accepts epoll_wait() as a valid sleeping
reason, but the prose only discusses clock_nanosleep and futexes. Add
epoll_wait to the list of valid sleeping reasons.
ABORT_SLEEP represents a task restoring TASK_RUNNING before entering
the scheduler, but its meaning is not described. Explain why the
aborted sleep attempt is valid.
This RFC is based on Nam Cao's pending "rv: rtapp monitor update" v2
series:
https://lore.kernel.org/r/cover.1781852967.git.namcao@linutronix.de
Signed-off-by: Chao Liu <chao.liu@processmission.com>
---
Documentation/trace/rv/monitor_rtapp.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/trace/rv/monitor_rtapp.rst b/Documentation/trace/rv/monitor_rtapp.rst
index 238b59395ff5..234ed4d581ac 100644
--- a/Documentation/trace/rv/monitor_rtapp.rst
+++ b/Documentation/trace/rv/monitor_rtapp.rst
@@ -67,6 +67,8 @@ thread to sleep for one of the following reasons:
variables as safe for real-time. As an alternative, the librtpi library
exists to provide a conditional variable implementation that is correct for
real-time applications in Linux.
+ - Real-time thread waiting for events using `epoll_wait`, which the monitor
+ accepts as a valid sleeping reason for real-time tasks.
Beside the reason for sleeping, the eventual waker should also be
real-time-safe. Namely, one of:
@@ -114,6 +116,10 @@ The monitor's specification is::
ALLOWLIST = BLOCK_ON_RT_MUTEX
or FUTEX_LOCK_PI
+`ABORT_SLEEP` represents a task restoring its state to `TASK_RUNNING` before
+entering the scheduler. In this case, the task does not actually block, so the
+monitor treats the aborted sleep attempt as valid.
+
Beside the scenarios described above, this specification also defines an allow list
to handle some special cases:
base-commit: 248951ddc14de84de3910f9b13f51491a8cd91df
prerequisite-patch-id: d8b6c952a954662852e6b0684e0a3386eaab7f41
prerequisite-patch-id: 940f7637aeabe4ba15a09c048c6f48138406f332
prerequisite-patch-id: b99812692691f76d825778e01a2e771e058febd6
prerequisite-patch-id: 512c300dce2cb74ac9cc007f9234aa507ef5c008
--
2.54.0
^ permalink raw reply related
* [PATCH 4/4] tracing/inject: Prevent overflow growing string fields
From: Li Qiang @ 2026-07-22 6:10 UTC (permalink / raw)
To: rostedt, mhiramat; +Cc: linux-trace-kernel, linux-kernel, Li Qiang, stable
In-Reply-To: <20260722061040.112747-1-liqiang01@kylinos.cn>
parse_entry() appends dynamic string data by adding its length to the
current entry size. An oversized input can overflow this signed addition,
cause krealloc() to receive too small a length, and then write beyond it.
Reject a string length that cannot be added to entry_size before growing
the allocation.
Fixes: 6c3edaf9fd6a ("tracing: Introduce trace event injection")
Cc: stable@vger.kernel.org
Signed-off-by: Li Qiang <liqiang01@kylinos.cn>
---
kernel/trace/trace_events_inject.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/trace_events_inject.c b/kernel/trace/trace_events_inject.c
index b8b141c00d5c..5c551def44f6 100644
--- a/kernel/trace/trace_events_inject.c
+++ b/kernel/trace/trace_events_inject.c
@@ -243,6 +243,9 @@ static int parse_entry(char *str, struct trace_event_call *call, void **pentry)
int str_loc = entry_size & 0xffff;
u32 *str_item;
+ if (str_len > INT_MAX - entry_size)
+ return -E2BIG;
+
entry_size += str_len;
*pentry = krealloc(entry, entry_size, GFP_KERNEL);
if (!*pentry) {
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] tracing/inject: Validate entry allocation size
From: Li Qiang @ 2026-07-22 6:10 UTC (permalink / raw)
To: rostedt, mhiramat; +Cc: linux-trace-kernel, linux-kernel, Li Qiang, stable
In-Reply-To: <20260722061040.112747-1-liqiang01@kylinos.cn>
trace_get_entry_size() calculated the allocation from signed field offsets
and sizes without validating their sum. A malformed event could use a
negative range or overflow the calculation, allocate too little memory, and
then write past it while initializing or populating the entry. Events with
no fields also allocated less than a trace_entry.
Start at sizeof(struct trace_entry), validate each field range, and reserve
room for the trailing NUL. Propagate sizing errors to parse_entry() before
it initializes the allocation.
Fixes: 6c3edaf9fd6a ("tracing: Introduce trace event injection")
Cc: stable@vger.kernel.org
Signed-off-by: Li Qiang <liqiang01@kylinos.cn>
---
kernel/trace/trace_events_inject.c | 31 ++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_events_inject.c b/kernel/trace/trace_events_inject.c
index a8f076809db4..b8b141c00d5c 100644
--- a/kernel/trace/trace_events_inject.c
+++ b/kernel/trace/trace_events_inject.c
@@ -135,27 +135,43 @@ parse_field(char *str, struct trace_event_call *call,
return -EINVAL;
}
-static int trace_get_entry_size(struct trace_event_call *call)
+static int trace_get_entry_size(struct trace_event_call *call, int *entry_size)
{
struct ftrace_event_field *field;
struct list_head *head;
- int size = 0;
+ int field_size;
+ int size = sizeof(struct trace_entry);
head = trace_get_fields(call);
list_for_each_entry(field, head, link) {
- if (field->size + field->offset > size)
- size = field->size + field->offset;
+ if (field->offset < 0 || field->size < 0 ||
+ field->size > INT_MAX - field->offset)
+ return -E2BIG;
+
+ field_size = field->size + field->offset;
+ if (field_size > size)
+ size = field_size;
}
- return size;
+ /* trace_alloc_entry() reserves an extra NUL byte. */
+ if (size == INT_MAX)
+ return -E2BIG;
+
+ *entry_size = size;
+ return 0;
}
static void *trace_alloc_entry(struct trace_event_call *call, int *size)
{
- int entry_size = trace_get_entry_size(call);
+ int entry_size;
struct ftrace_event_field *field;
struct list_head *head;
void *entry = NULL;
+ int ret;
+
+ ret = trace_get_entry_size(call, &entry_size);
+ if (ret)
+ return ERR_PTR(ret);
/* We need an extra '\0' at the end. */
entry = kzalloc(entry_size + 1, GFP_KERNEL);
@@ -202,6 +218,9 @@ static int parse_entry(char *str, struct trace_event_call *call, void **pentry)
int len;
entry = trace_alloc_entry(call, &entry_size);
+ if (IS_ERR(entry))
+ return PTR_ERR(entry);
+
*pentry = entry;
if (!entry)
return -ENOMEM;
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] tracing/user_events: Validate explicit struct field sizes
From: Li Qiang @ 2026-07-22 6:10 UTC (permalink / raw)
To: rostedt, mhiramat; +Cc: linux-trace-kernel, linux-kernel, Li Qiang, stable
In-Reply-To: <20260722061040.112747-1-liqiang01@kylinos.cn>
User event declarations permit an explicit size for a struct field. The
parser accumulated that size in an unsigned offset, then assigned the
parsed unsigned value directly to signed field metadata. Oversized
declarations or cumulative offsets could wrap or become invalid signed
values.
Validate an explicit size is representable as int before storing it. Keep
the running offset signed and reject additions exceeding INT_MAX, so
invalid field layouts are rejected during declaration parsing.
Fixes: 7f5a08c79df3 ("user_events: Add minimal support for trace_event into ftrace")
Cc: stable@vger.kernel.org
Signed-off-by: Li Qiang <liqiang01@kylinos.cn>
---
kernel/trace/trace_events_user.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 8c82ecb735f4..fd5b3946921c 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -1197,10 +1197,12 @@ static int user_event_add_field(struct user_event *user, const char *type,
* Format: type name [size]
*/
static int user_event_parse_field(char *field, struct user_event *user,
- u32 *offset)
+ int *offset)
{
char *part, *type, *name;
- u32 depth = 0, saved_offset = *offset;
+ u32 depth = 0;
+ unsigned int field_size;
+ int saved_offset = *offset;
int len, size = -EINVAL;
bool is_struct = false;
@@ -1261,8 +1263,11 @@ static int user_event_parse_field(char *field, struct user_event *user,
if (!is_struct)
return -EINVAL;
- if (kstrtou32(part, 10, &size))
+ if (kstrtouint(part, 10, &field_size))
return -EINVAL;
+ if (field_size > INT_MAX)
+ return -E2BIG;
+ size = field_size;
break;
default:
return -EINVAL;
@@ -1281,6 +1286,9 @@ static int user_event_parse_field(char *field, struct user_event *user,
if (size < 0)
return size;
+ if (size > INT_MAX - saved_offset)
+ return -E2BIG;
+
*offset = saved_offset + size;
return user_event_add_field(user, type, name, saved_offset, size,
@@ -1290,7 +1298,7 @@ static int user_event_parse_field(char *field, struct user_event *user,
static int user_event_parse_fields(struct user_event *user, char *args)
{
char *field;
- u32 offset = sizeof(struct trace_entry);
+ int offset = sizeof(struct trace_entry);
int ret = -EINVAL;
if (args == NULL)
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox