* Re: [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption
From: Masami Hiramatsu @ 2026-07-20 14:24 UTC (permalink / raw)
To: Borislav Petkov, Jinchao Wang
Cc: Dave Hansen, Jinchao Wang, Andrew Morton, Peter Zijlstra,
Thomas Gleixner, Steven Rostedt, Masami Hiramatsu, 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: <20260717181004.GBalpv_MOaAflgFxgh@fat_crate.local>
On Fri, 17 Jul 2026 11:10:04 -0700
Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Jul 17, 2026 at 06:41:49AM -0700, 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.
>
> Right, and in my mbox right under this mail thread there's a
>
> https://lore.kernel.org/all/178429796992.157981.3393977217853767915.stgit@devnote2/
>
> which Masami has been blasting almost every day this week which contains two
> of the patches from this set here...
Sorry about that. I tried to fix the reviewed comment from Sashiko,
but I should wait for someone's comment.
>
> 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,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 06/11] rcu: Enable RCU callbacks to benefit from expedited grace periods
From: Frederic Weisbecker @ 2026-07-20 14:22 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: <6c683413-8e8b-4888-ba01-9d79c3867432@paulmck-laptop>
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.
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: Linking Patchwork with Sashiko?
From: Steven Rostedt @ 2026-07-20 13:36 UTC (permalink / raw)
To: Roman Gushchin; +Cc: Masami Hiramatsu, Linux trace kernel
In-Reply-To: <7ia4wluvvlq4.fsf@castle.c.googlers.com>
[ Removed all Cc's. Added Masami and linux-trace-kernel mailing list ]
On Thu, 16 Jul 2026 00:09:39 +0000
Roman Gushchin <roman.gushchin@linux.dev> wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:
>
> > On Wed, 15 Jul 2026 21:08:47 +0000
> > Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> >> At this moment there are 36 mailing lists who opted in for delivering email
> >> reviews over email (without counting linux-media@). In every single case
> >> it was based on maintainers requests in all cases of a disagreement
> >> between maintainers I took the conservative side.
> >
> > Oh, I think I missed this opt-in. Can you add replies to patches sent
> > to linux-trace-kernel. Currently, I've been manually looking to see if
> > a patch had a Sashiko review and sending the author a link to the
> > review and told them to please reply to the comments.
> >
> > Note, I have not had anyone tell me the are against doing so.
>
> May I ask you to raise this question with other linux-trace-kernel
> maintainers and cc me on the thread? Just to make sure everyone is
> onboard.
Masami,
Are you OK with having Sashiko send an email on what it finds to the
author and the mailing list?
>
> Also, please, let me know if sashiko should reply to the author and
> also if it should send an email if there are no issues found.
I think if it finds no issues it should still send the email, as it
adds to the confidence of the patch. It also lets us know that the
email wasn't just dropped.
Oh, I would think that "Failed to apply" results should *not* be sent.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH v4 09/13] verification/rvgen: Delete __parse_constraint()
From: Gabriele Monaco @ 2026-07-20 12:13 UTC (permalink / raw)
To: Nam Cao
Cc: Steven Rostedt, Wander Lairson Costa, linux-trace-kernel,
linux-kernel
In-Reply-To: <87ik69evgy.fsf@yellow.woof>
On Mon, 2026-07-20 at 13:44 +0200, Nam Cao wrote:
> Hi Gabriele,
>
> Gabriele Monaco <gmonaco@redhat.com> writes:
> > The series looks ready for inclusion to me, thanks!
>
> For patches that you have applied, can you push them to your tree? I
> think that is
> https://git.kernel.org/pub/scm/linux/kernel/git/gmonaco/linux.git/ ?
>
> I would like to have a base for my other patches, to identify conflicts.
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
> It is also useful to include them in linux-next to get some more
> testing.
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?
Gabriele
^ permalink raw reply
* Re: [PATCH v4 09/13] verification/rvgen: Delete __parse_constraint()
From: Nam Cao @ 2026-07-20 11:44 UTC (permalink / raw)
To: Gabriele Monaco
Cc: Steven Rostedt, Wander Lairson Costa, linux-trace-kernel,
linux-kernel
In-Reply-To: <5bd5c857c5130dd7b122112c69baf793bcf45090.camel@redhat.com>
Hi Gabriele,
Gabriele Monaco <gmonaco@redhat.com> writes:
> The series looks ready for inclusion to me, thanks!
For patches that you have applied, can you push them to your tree? I
think that is
https://git.kernel.org/pub/scm/linux/kernel/git/gmonaco/linux.git/ ?
I would like to have a base for my other patches, to identify conflicts.
It is also useful to include them in linux-next to get some more
testing.
Thanks,
Nam
^ permalink raw reply
* Re: [PATCH v4 4/8] rv/ha: fix ha_invariant_passed_ns silent bypass of invariant check
From: Gabriele Monaco @ 2026-07-20 11:31 UTC (permalink / raw)
To: wen.yang; +Cc: Nam Cao, linux-trace-kernel, linux-kernel
In-Reply-To: <d83c7bff76922ba464d328758ec24b7bf41d4824.1783524627.git.wen.yang@linux.dev>
On Wed, 2026-07-08 at 23:38 +0800, wen.yang@linux.dev wrote:
> From: Wen Yang <wen.yang@linux.dev>
>
> When env_store is U64_MAX (its initial sentinel value),
> ha_invariant_passed_ns() returns 0 immediately without initializing
> env_store to the current clock. Subsequent calls to
> ha_check_invariant_ns() then find env_store still at U64_MAX, causing
> the elapsed comparison to wrap and always report the invariant as
> satisfied, silently masking any violations.
>
> Fix by calling ha_reset_clk_ns() to establish the guard on the first
> invocation instead of returning early. Apply the same fix to
> ha_invariant_passed_jiffy().
>
> Signed-off-by: Wen Yang <wen.yang@linux.dev>
While this looks alright, I have something else in mind for the env variables
lifecycle. After [1] is merged, I'd like to merge [2] which is basically
inspired on your idea of resetting variables on start, just it's embedded in the
framework (and requires [1] to get rid of the double representation for env
variables).
This is probably going to happen after the next merge window.
I believe you can keep this patch for now and your model wouldn't need change
after adding [2] instead.
Thoughts?
Thanks,
Gabriele
[1] -
https://lore.kernel.org/lkml/c0f600dcbf3d8b487c944406851a39146f4d91fa.1781847583.git.namcao@linutronix.de/
[2] -
https://web.git.kernel.org/pub/scm/linux/kernel/git/gmonaco/linux.git/commit/?h=rv_hybrid_automata_enq_lark&id=d7c5c40c81d9b928aa9f86c4115429bffd223a8c
> ---
> include/rv/ha_monitor.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/rv/ha_monitor.h b/include/rv/ha_monitor.h
> index 83199f90afe8..dddf5694bcc8 100644
> --- a/include/rv/ha_monitor.h
> +++ b/include/rv/ha_monitor.h
> @@ -375,12 +375,12 @@ static inline bool ha_check_invariant_ns(struct
> ha_monitor *ha_mon,
> static inline u64 ha_invariant_passed_ns(struct ha_monitor *ha_mon, enum envs
> env,
> u64 expire, u64 time_ns)
> {
> - u64 passed = 0;
> + u64 passed;
>
> if (env < 0 || env >= ENV_MAX_STORED)
> return 0;
> if (ha_monitor_env_invalid(ha_mon, env))
> - return 0;
> + ha_reset_clk_ns(ha_mon, env, time_ns);
> passed = ha_get_env(ha_mon, env, time_ns);
> ha_set_invariant_ns(ha_mon, env, expire - passed, time_ns);
> return passed;
> @@ -414,12 +414,12 @@ static inline bool ha_check_invariant_jiffy(struct
> ha_monitor *ha_mon,
> static inline u64 ha_invariant_passed_jiffy(struct ha_monitor *ha_mon, enum
> envs env,
> u64 expire, u64 time_ns)
> {
> - u64 passed = 0;
> + u64 passed;
>
> if (env < 0 || env >= ENV_MAX_STORED)
> return 0;
> if (ha_monitor_env_invalid(ha_mon, env))
> - return 0;
> + ha_reset_clk_jiffy(ha_mon, env);
> passed = ha_get_env(ha_mon, env, time_ns);
> ha_set_invariant_jiffy(ha_mon, env, expire - passed);
> return passed;
^ permalink raw reply
* Re: [PATCH v4 17/17] selftests/verification: Add selftests for deadline and stall monitors
From: Nam Cao @ 2026-07-20 11:03 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, linux-trace-kernel, Steven Rostedt,
Gabriele Monaco, Shuah Khan, linux-kselftest
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260717154638.220789-18-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> + stress-ng --cpu 2 --sched deadline --sched-period 100000000 --sched-deadline 100000000 --sched-runtime 20000000 -t 5 &
> + stress-ng --cpu 2 --sched rr --sched-prio 50 --cyclic 1 --cyclic-policy rr --cyclic-prio 50 -t 5 &
These exceed the 100 column limit.
Other than that:
Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [PATCH v4 16/17] selftests/verification: Rearrange the wwnr_printk test
From: Nam Cao @ 2026-07-20 11:01 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, linux-trace-kernel, Steven Rostedt,
Gabriele Monaco, Shuah Khan, linux-kselftest
Cc: Wen Yang, Thomas Weissschuh, Tomas Glozar, John Kacur
In-Reply-To: <20260717154638.220789-17-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> The wwnr_printk test expects no reactions in some situations, after
> fixing the bash assertion, the test is failing because expecting no
> reaction after a previous step had reactions is flaky without making
> sure all buffers are flushed.
>
> Wait for reactions to be over when expected by polling dmesg for an
> interval without any rv message.
> Also simplify the load function to stop loads as soon as a reaction
> occurs, this limits the number of lines to flush and makes tests overall
> faster and more stable.
>
> Reviewed-by: Wen Yang <wen.yang@linux.dev>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [PATCH v4 09/17] verification/rvgen: Add the rvgen kunit subcommand
From: Nam Cao @ 2026-07-20 10:54 UTC (permalink / raw)
To: Gabriele Monaco, linux-kernel, linux-trace-kernel, Steven Rostedt,
Gabriele Monaco
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260717154638.220789-10-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> Add the rvgen kunit subcommand to patch an already generated monitor for
> kunit support. It parses the handlers and create the necessary structs
> and initialisations.
>
> The only remaining manual steps are importing the test in the runner
> and writing the test itself.
>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* [PATCH 10/10] tracing/probes: Fix extra whitespace in trace_probe_kernel.h
From: Masami Hiramatsu (Google) @ 2026-07-20 10:45 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Clean up extra space after '=' in fetch_store_strlen_user().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe_kernel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_probe_kernel.h b/kernel/trace/trace_probe_kernel.h
index bb723eefd7b7..4eb4acfa09ba 100644
--- a/kernel/trace/trace_probe_kernel.h
+++ b/kernel/trace/trace_probe_kernel.h
@@ -12,7 +12,7 @@
static nokprobe_inline int
fetch_store_strlen_user(unsigned long addr)
{
- const void __user *uaddr = (__force const void __user *)addr;
+ const void __user *uaddr = (__force const void __user *)addr;
return strnlen_user_nofault(uaddr, MAX_STRING_SIZE);
}
^ permalink raw reply related
* [PATCH 09/10] tracing/kprobe: Remove redundant memset in kprobe_perf_func()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:44 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
kprobe_perf_func() calls memset(&entry[1], 0, dsize) prior to calling
store_trace_args(). store_trace_args() populates the entry buffer and
handles dynamic data fields.
Remove this redundant memset call to align with kretprobe_perf_func() and
other probe perf functions.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_kprobe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index cc24e992732c..c25f902aa1a6 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1721,7 +1721,6 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs)
return 0;
entry->ip = (unsigned long)tk->rp.kp.addr;
- memset(&entry[1], 0, dsize);
store_trace_args(&entry[1], &tk->tp, regs, NULL, sizeof(*entry), dsize);
perf_trace_buf_submit(entry, size, rctx, call->event.type, 1, regs,
head, NULL);
^ permalink raw reply related
* [PATCH 08/10] tracing/fprobe: Remove redundant memset in fentry_perf_func()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:44 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
fentry_perf_func() calls memset(&entry[1], 0, dsize) prior to calling
store_trace_args(). store_trace_args() populates the entry buffer and
handles dynamic data fields.
Furthermore, passing dsize (the dynamic data byte length) to memset at
&entry[1] (the start of fixed trace arguments) is inaccurate as it zeroes
from the fixed args area rather than the dynamic data region.
Remove this redundant memset call to align with fexit_perf_func() and other
probe perf functions.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_fprobe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/trace_fprobe.c b/kernel/trace/trace_fprobe.c
index 566b64853c61..ec9105fca4a6 100644
--- a/kernel/trace/trace_fprobe.c
+++ b/kernel/trace/trace_fprobe.c
@@ -471,7 +471,6 @@ static int fentry_perf_func(struct trace_fprobe *tf, unsigned long entry_ip,
regs = ftrace_fill_perf_regs(fregs, regs);
entry->ip = entry_ip;
- memset(&entry[1], 0, dsize);
store_trace_args(&entry[1], &tf->tp, fregs, NULL, sizeof(*entry), dsize);
perf_trace_buf_submit(entry, size, rctx, call->event.type, 1, regs,
head, NULL);
^ permalink raw reply related
* [PATCH 07/10] tracing/fprobe: Remove redundant snprintf in trace_fprobe_match_command_head()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:44 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
trace_fprobe_match_command_head() copies trace_fprobe_symbol(tf) into a
local buffer 'buf' of size MAX_COMMON_HEAD_LEN + 1 using snprintf before
comparing with argv[0].
Since trace_fprobe_symbol(tf) already returns a null-terminated string,
comparing it directly with argv[0] via strcmp() avoids stack buffer usage
and potential symbol truncation at MAX_COMMON_HEAD_LEN.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_fprobe.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/trace/trace_fprobe.c b/kernel/trace/trace_fprobe.c
index 5638a90e61cc..566b64853c61 100644
--- a/kernel/trace/trace_fprobe.c
+++ b/kernel/trace/trace_fprobe.c
@@ -238,13 +238,10 @@ static bool trace_fprobe_is_busy(struct dyn_event *ev)
static bool trace_fprobe_match_command_head(struct trace_fprobe *tf,
int argc, const char **argv)
{
- char buf[MAX_COMMON_HEAD_LEN + 1];
-
if (!argc)
return true;
- snprintf(buf, sizeof(buf), "%s", trace_fprobe_symbol(tf));
- if (strcmp(buf, argv[0]))
+ if (strcmp(trace_fprobe_symbol(tf), argv[0]))
return false;
argc--; argv++;
^ permalink raw reply related
* [PATCH 06/10] tracing/probes: Simplify BTF_KIND_PTR case in fetch_type_from_btf_type()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:44 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Use a ternary operator for checking IS_ENABLED(CONFIG_64BIT) in the
BTF_KIND_PTR case of fetch_type_from_btf_type() to simplify the code.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 4899aa5f9230..fc62d09ea535 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -495,10 +495,7 @@ static const char *fetch_type_from_btf_type(struct btf *btf,
return "s64";
case BTF_KIND_PTR:
/* pointer will be converted to "x??" */
- if (IS_ENABLED(CONFIG_64BIT))
- return "x64";
- else
- return "x32";
+ return IS_ENABLED(CONFIG_64BIT) ? "x64" : "x32";
case BTF_KIND_INT:
intdata = btf_type_int(type);
if (BTF_INT_ENCODING(intdata) & BTF_INT_SIGNED) {
^ permalink raw reply related
* [PATCH 05/10] tracing/probes: Cleanup pointer arithmetic in store_trace_entry_data()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:44 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
In store_trace_entry_data(), edata is cast to unsigned long for pointer
offset arithmetic before being cast back to unsigned long *. Cast edata
to u8 * instead.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index eb7be3725e85..4899aa5f9230 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -1246,7 +1246,7 @@ void store_trace_entry_data(void *edata, struct trace_probe *tp, struct pt_regs
val = regs_get_kernel_argument(regs, code->param);
break;
case FETCH_OP_ST_EDATA:
- *(unsigned long *)((unsigned long)edata + code->offset) = val;
+ *(unsigned long *)((u8 *)edata + code->offset) = val;
break;
case FETCH_OP_END:
goto end;
^ permalink raw reply related
* [PATCH 04/10] tracing/probes: Remove unused parameter from parse_probe_var_retval()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:44 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
The parameter 'arg' in parse_probe_var_retval() is unused. Remove it
and update its caller accordingly.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 91ba4490937b..eb7be3725e85 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -1262,7 +1262,7 @@ NOKPROBE_SYMBOL(store_trace_entry_data)
#define PARAM_MAX_STACK (THREAD_SIZE / sizeof(unsigned long))
-static int parse_probe_var_retval(char *orig_arg, char *arg,
+static int parse_probe_var_retval(char *orig_arg,
struct fetch_insn **pcode,
struct fetch_insn *end,
struct traceprobe_parse_context *ctx)
@@ -1415,7 +1415,7 @@ static int parse_probe_vars(char *orig_arg, const struct fetch_type *t,
goto inval;
if (str_has_prefix(arg, "retval"))
- return parse_probe_var_retval(orig_arg, arg, pcode, end, ctx);
+ return parse_probe_var_retval(orig_arg, pcode, end, ctx);
len = str_has_prefix(arg, "stack");
if (len)
^ permalink raw reply related
* [PATCH 03/10] tracing/probes: Remove redundant bounds check in trace_probe_compare_arg_type()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:43 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
In trace_probe_compare_arg_type(), prior to entering the comparison loop,
a->nr_args and b->nr_args are checked for equality. Since the loop
condition is i < a->nr_args, i is guaranteed to be less than b->nr_args
inside the loop.
Remove the redundant (b->nr_args <= i) check.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 7568f5e68de7..91ba4490937b 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -2770,10 +2770,9 @@ int trace_probe_compare_arg_type(struct trace_probe *a, struct trace_probe *b)
return b->nr_args + 1;
for (i = 0; i < a->nr_args; i++) {
- if ((b->nr_args <= i) ||
- ((a->args[i].type != b->args[i].type) ||
- (a->args[i].count != b->args[i].count) ||
- strcmp(a->args[i].name, b->args[i].name)))
+ if ((a->args[i].type != b->args[i].type) ||
+ (a->args[i].count != b->args[i].count) ||
+ strcmp(a->args[i].name, b->args[i].name))
return i + 1;
}
^ permalink raw reply related
* [PATCH 02/10] tracing/probes: Remove redundant boolean conversion in trace_probe_has_single_file()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:43 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
list_is_singular() returns a boolean value, so the double negation (!!)
in trace_probe_has_single_file() is redundant. Remove it.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index b3571c85abb1..c0f05763811c 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -360,7 +360,7 @@ static inline int trace_probe_unregister_event_call(struct trace_probe *tp)
static inline bool trace_probe_has_single_file(struct trace_probe *tp)
{
- return !!list_is_singular(&tp->event->files);
+ return list_is_singular(&tp->event->files);
}
int trace_probe_init(struct trace_probe *tp, const char *event,
^ permalink raw reply related
* [PATCH 01/10] tracing/probes: Remove duplicate MAX_ARRAY_LEN macro definition
From: Masami Hiramatsu (Google) @ 2026-07-20 10:43 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <178454420994.296567.10239174745865301350.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
MAX_ARRAY_LEN is defined twice in trace_probe.h. Remove the redundant
definition.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index ebdc706e7cb6..b3571c85abb1 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -220,7 +220,6 @@ DECLARE_BASIC_PRINT_TYPE_FUNC(symbol);
_ASSIGN_FETCH_TYPE(#ptype, ptype, ftype, sizeof(ftype), sign, atype)
#define ASSIGN_FETCH_TYPE_END {}
-#define MAX_ARRAY_LEN 64
#ifdef CONFIG_KPROBE_EVENTS
bool trace_kprobe_on_func_entry(struct trace_event_call *call);
^ permalink raw reply related
* [PATCH 00/10] tracing/probes: Cleanup probe event code
From: Masami Hiramatsu (Google) @ 2026-07-20 10:43 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
Hi,
Here are a patches to cleanup the probe events related code
(kernel/trace/trace_*probe*).
Thank you,
---
base-commit: 1a416ae446afa42d2d8500ce25bd61c564508721
Masami Hiramatsu (Google) (10):
tracing/probes: Remove duplicate MAX_ARRAY_LEN macro definition
tracing/probes: Remove redundant boolean conversion in trace_probe_has_single_file()
tracing/probes: Remove redundant bounds check in trace_probe_compare_arg_type()
tracing/probes: Remove unused parameter from parse_probe_var_retval()
tracing/probes: Cleanup pointer arithmetic in store_trace_entry_data()
tracing/probes: Simplify BTF_KIND_PTR case in fetch_type_from_btf_type()
tracing/fprobe: Remove redundant snprintf in trace_fprobe_match_command_head()
tracing/fprobe: Remove redundant memset in fentry_perf_func()
tracing/kprobe: Remove redundant memset in kprobe_perf_func()
tracing/probes: Fix extra whitespace in trace_probe_kernel.h
kernel/trace/trace_fprobe.c | 6 +-----
kernel/trace/trace_kprobe.c | 1 -
kernel/trace/trace_probe.c | 18 +++++++-----------
kernel/trace/trace_probe.h | 3 +--
kernel/trace/trace_probe_kernel.h | 2 +-
5 files changed, 10 insertions(+), 20 deletions(-)
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/8] rv/da: introduce DA_MON_ALLOCATION_STRATEGY
From: Gabriele Monaco @ 2026-07-20 10:23 UTC (permalink / raw)
To: wen.yang; +Cc: Nam Cao, linux-trace-kernel, linux-kernel
In-Reply-To: <42cda27998fca0ca2573baac60a01ab9620b91f0.1783524627.git.wen.yang@linux.dev>
On Wed, 2026-07-08 at 23:38 +0800, wen.yang@linux.dev wrote:
> From: Wen Yang <wen.yang@linux.dev>
> diff --git a/include/rv/ha_monitor.h b/include/rv/ha_monitor.h
> index 28d3c74cabfc..83199f90afe8 100644
> --- a/include/rv/ha_monitor.h
> +++ b/include/rv/ha_monitor.h
> @@ -365,6 +365,12 @@ static inline bool ha_check_invariant_ns(struct
> ha_monitor *ha_mon,
> }
> /*
> * ha_invariant_passed_ns - prepare the invariant and return the time since
> reset
> + *
> + * If the env has not been initialised yet (first entry into a state with an
> + * invariant), anchor the guard clock at the current time so that the full
> + * budget is available from this point. This preserves the documented
> + * guard->invariant ordering: ha_set_invariant_ns() is always preceded by a
> + * valid guard representation in env_store.
> */
> static inline u64 ha_invariant_passed_ns(struct ha_monitor *ha_mon, enum envs
> env,
> u64 expire, u64 time_ns)
This hunk belongs to a later patch, doesn't it?
^ permalink raw reply
* [PATCH 4/4] tracing/eprobe: Fix exact system name matching in eprobe_dyn_event_match()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:12 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers
Cc: linux-kernel, linux-trace-kernel
In-Reply-To: <178454232006.290363.11301475407231432622.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
eprobe_dyn_event_match() checks if the target event system in argv[0]
matches ep->event_system using strncmp(ep->event_system, argv[0], len).
However, if ep->event_system is longer than len (e.g. "eprobes" vs
"ep/event"), strncmp() still returns 0 because the first len characters
match.
Check that ep->event_system[len] is '\0' to ensure exact system name
matching.
Fixes: 7d5fda1c841f ("tracing: Fix event probe removal from dynamic events")
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_eprobe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_eprobe.c b/kernel/trace/trace_eprobe.c
index 50518b071414..bcd97cb24ac9 100644
--- a/kernel/trace/trace_eprobe.c
+++ b/kernel/trace/trace_eprobe.c
@@ -172,7 +172,8 @@ static bool eprobe_dyn_event_match(const char *system, const char *event,
if (!slash)
return false;
- if (strncmp(ep->event_system, argv[0], slash - argv[0]))
+ if (strncmp(ep->event_system, argv[0], slash - argv[0]) ||
+ ep->event_system[slash - argv[0]] != '\0')
return false;
if (strcmp(ep->event_name, slash + 1))
return false;
^ permalink raw reply related
* [PATCH 3/4] tracing/probes: Fix potential underflow in LEN_OR_ZERO macro
From: Masami Hiramatsu (Google) @ 2026-07-20 10:12 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers
Cc: linux-kernel, linux-trace-kernel
In-Reply-To: <178454232006.290363.11301475407231432622.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
In __set_print_fmt(), LEN_OR_ZERO is defined as (len ? len - pos : 0).
If len is non-zero but smaller than pos, len - pos evaluates to a negative
integer. When passed as a size argument to snprintf(), this negative value
is cast to a large unsigned size_t, bypassing buffer size limits.
Ensure len > pos before subtracting to avoid integer underflow.
Fixes: 5bf652aaf46c ("tracing/probes: Integrate duplicate set_print_fmt()")
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 49daa3cc2a45..506e6037e163 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -2013,7 +2013,7 @@ int traceprobe_update_arg(struct probe_arg *arg)
}
/* When len=0, we just calculate the needed length */
-#define LEN_OR_ZERO (len ? len - pos : 0)
+#define LEN_OR_ZERO (len > pos ? len - pos : 0)
static int __set_print_fmt(struct trace_probe *tp, char *buf, int len,
enum probe_print_type ptype)
{
^ permalink raw reply related
* [PATCH 2/4] tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:12 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers
Cc: linux-kernel, linux-trace-kernel
In-Reply-To: <178454232006.290363.11301475407231432622.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
If trace_probe_log.argc is 0 in __trace_probe_log_err(), the loop
constructing the command string will not execute and p will remain equal to
command. Writing to *(p - 1) will cause an out-of-bounds access before
command. This should not happen, but better to be treated.
Reject if trace_probe_log.argc is 0.
Fixes: ab105a4fb894 ("tracing: Use tracing error_log with probe events")
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 95e3d072321f..49daa3cc2a45 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -188,7 +188,7 @@ void __trace_probe_log_err(int offset, int err_type)
lockdep_assert_held(&dyn_event_ops_mutex);
- if (!trace_probe_log.argv)
+ if (!trace_probe_log.argv || !trace_probe_log.argc)
return;
/* Recalculate the length and allocate buffer */
^ permalink raw reply related
* [PATCH 1/4] tracing/probes: Avoid temporary buffer truncation in trace_probe_match_command_args()
From: Masami Hiramatsu (Google) @ 2026-07-20 10:12 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers
Cc: linux-kernel, linux-trace-kernel
In-Reply-To: <178454232006.290363.11301475407231432622.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
In trace_probe_match_command_args(), a stack buffer buf[MAX_ARGSTR_LEN + 1]
(256 bytes) is used to format "<name>=<comm>". However, since name can
be up to 32 bytes (MAX_ARG_NAME_LEN) and comm up to 255 bytes
(MAX_ARGSTR_LEN), the formatted string can exceed 256 bytes and get
truncated by snprintf(), causing spurious argument matching failures.
Instead of formatting into a temporary buffer on stack, compare the
argument name, the '=' delimiter, and the comm expression directly.
Fixes: eb5bf81330a7 ("tracing/kprobe: Add per-probe delete from event")
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index d17cfee77d9c..95e3d072321f 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -2338,16 +2338,17 @@ int trace_probe_compare_arg_type(struct trace_probe *a, struct trace_probe *b)
bool trace_probe_match_command_args(struct trace_probe *tp,
int argc, const char **argv)
{
- char buf[MAX_ARGSTR_LEN + 1];
int i;
if (tp->nr_args < argc)
return false;
for (i = 0; i < argc; i++) {
- snprintf(buf, sizeof(buf), "%s=%s",
- tp->args[i].name, tp->args[i].comm);
- if (strcmp(buf, argv[i]))
+ int len = strlen(tp->args[i].name);
+
+ if (strncmp(argv[i], tp->args[i].name, len) ||
+ argv[i][len] != '=' ||
+ strcmp(argv[i] + len + 1, tp->args[i].comm))
return false;
}
return true;
^ 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