From: sashiko-bot@kernel.org
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v7 02/10] x86: hw_breakpoint: Add a kconfig to clarify when a breakpoint fires
Date: Wed, 15 Jul 2026 01:57:40 +0000 [thread overview]
Message-ID: <20260715015741.1394D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <178407986179.95826.1630626264869856006.stgit@devnote2>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Memory leak of the `symbol` string in `__trace_wprobe_create()`.
- [Medium] `enable_trace_wprobe()` fails to rollback trace probe state on hardware breakpoint registration error, leading to state inconsistency and silent tracing failures.
--
--- Patch [2]: [PATCH v7 02/10] x86: hw_breakpoint: Add a kconfig to clarify when a breakpoint fires ---
commit f8a7aeb231575f15f9227ab411134bde7408e480
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
tracing: wprobe: Add watchpoint probe event based on hardware breakpoint
Add a new probe event for the hardware breakpoint called wprobe-event.
This wprobe allows user to trace (watch) the memory access at the
specified memory address. The events can be defined via the dynamic_events
interface file.
Link: https://lore.kernel.org/all/175859021100.374439.8723137923620348816.stgit@devnote2/
> diff --git a/kernel/trace/trace_wprobe.c b/kernel/trace/trace_wprobe.c
> new file mode 100644
> index 0000000000000..b52f3eac719f9
> --- /dev/null
> +++ b/kernel/trace/trace_wprobe.c
> @@ -0,0 +1,692 @@
[ ... ]
> +static int enable_trace_wprobe(struct trace_event_call *call,
> + struct trace_event_file *file)
> +{
> + struct trace_probe *tp;
> + struct trace_wprobe *tw;
> + bool enabled;
> + int ret = 0;
> +
> + tp = trace_probe_primary_from_call(call);
> + if (WARN_ON_ONCE(!tp))
> + return -ENODEV;
> + enabled = trace_probe_is_enabled(tp);
> +
> + if (file) {
> + ret = trace_probe_add_file(tp, file);
> + if (ret)
> + return ret;
> + } else {
> + trace_probe_set_flag(tp, TP_FLAG_PROFILE);
> + }
> +
> + if (!enabled) {
> + list_for_each_entry(tw, trace_probe_probe_list(tp), tp.list) {
> + ret = __register_trace_wprobe(tw);
> + if (ret < 0) {
> + /* TODO: rollback */
> + return ret;
[Severity: Medium]
Will this leave the trace probe state inconsistent if hardware breakpoint
registration fails?
Earlier in enable_trace_wprobe(), trace_probe_add_file() or
trace_probe_set_flag() modify the probe state. If __register_trace_wprobe()
returns an error, the function returns immediately without rolling back those
changes.
Could this cause subsequent enable attempts to skip registration entirely and
silently fail to trace?
> + }
> + }
> + }
> +
> + return 0;
> +}
[ ... ]
> +static int __trace_wprobe_create(int argc, const char *argv[])
> +{
> + /*
> + * Argument syntax:
> + * b[:[GRP/][EVENT]] SPEC
> + *
> + * SPEC:
> + * [r|w|rw]@[ADDR|SYMBOL[+OFFS]][:LEN]
> + */
> + struct traceprobe_parse_context *ctx __free(traceprobe_parse_context) = NULL;
> + struct trace_wprobe *tw __free(free_trace_wprobe) = NULL;
> + const char *event = NULL, *group = WPROBE_EVENT_SYSTEM;
> + const char *tplog __free(trace_probe_log_clear) = NULL;
> + char *symbol = NULL;
> + unsigned long addr;
> + int len, type, i;
> + int ret = 0;
> +
> + if (argv[0][0] != 'w')
> + return -ECANCELED;
> +
> + if (argc < 2)
> + return -EINVAL;
> +
> + tplog = trace_probe_log_init("wprobe", argc, argv);
> +
> + if (argv[0][1] != '\0') {
> + if (argv[0][1] != ':') {
> + trace_probe_log_set_index(0);
> + trace_probe_log_err(1, BAD_MAXACT_TYPE);
> + /* Invalid format */
> + return -EINVAL;
> + }
> + event = &argv[0][2];
> + }
> +
> + trace_probe_log_set_index(1);
> + ret = parse_address_spec(argv[1], &addr, &type, &len, &symbol);
> + if (ret < 0)
> + return ret;
> +
> + if (!event)
> + event = symbol ? symbol : "wprobe";
> +
> + argc -= 2; argv += 2;
> + tw = alloc_trace_wprobe(group, event, symbol, addr, len, type, argc);
> + if (IS_ERR(tw))
> + return PTR_ERR(tw);
[Severity: Medium]
Does this code leak the symbol string?
When a wprobe event is created using a symbol name, parse_address_spec()
allocates a string for symbol. This string is then passed to
alloc_trace_wprobe() which duplicates it again using kstrdup().
However, the original symbol pointer does not appear to be freed before
__trace_wprobe_create() returns. Should symbol be annotated with __free(kfree)
or explicitly freed?
> +
> + ctx = kzalloc_obj(*ctx);
> + if (!ctx)
> + return -ENOMEM;
--
Sashiko AI review · https://sashiko.dev/#/patchset/178407983818.95826.12714571928538799781.stgit@devnote2?part=2
next prev parent reply other threads:[~2026-07-15 1:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 1:43 [PATCH v7 00/10] tracing: wprobe: x86: Add wprobe for watchpoint Masami Hiramatsu (Google)
2026-07-15 1:44 ` [PATCH v7 01/10] tracing: wprobe: Add watchpoint probe event based on hardware breakpoint Masami Hiramatsu (Google)
2026-07-15 2:01 ` sashiko-bot
2026-07-15 1:44 ` [PATCH v7 02/10] x86: hw_breakpoint: Add a kconfig to clarify when a breakpoint fires Masami Hiramatsu (Google)
2026-07-15 1:57 ` sashiko-bot [this message]
2026-07-15 1:44 ` [PATCH v7 03/10] selftests: tracing: Add a basic testcase for wprobe Masami Hiramatsu (Google)
2026-07-15 1:52 ` sashiko-bot
2026-07-15 1:44 ` [PATCH v7 04/10] selftests: tracing: Add syntax " Masami Hiramatsu (Google)
2026-07-15 1:44 ` [PATCH v7 05/10] tracing: wprobe: Use a new seq_print_ip_sym_offset() wrapper Masami Hiramatsu (Google)
2026-07-15 2:02 ` sashiko-bot
2026-07-15 1:45 ` [PATCH v7 06/10] x86/hw_breakpoint: Unify breakpoint install/uninstall Masami Hiramatsu (Google)
2026-07-15 1:59 ` sashiko-bot
2026-07-15 1:45 ` [PATCH v7 07/10] x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint Masami Hiramatsu (Google)
2026-07-15 2:13 ` sashiko-bot
2026-07-15 1:45 ` [PATCH v7 08/10] HWBP: Add modify_wide_hw_breakpoint_local() API Masami Hiramatsu (Google)
2026-07-15 2:00 ` sashiko-bot
2026-07-15 1:45 ` [PATCH v7 09/10] tracing: wprobe: Add wprobe event trigger Masami Hiramatsu (Google)
2026-07-15 2:05 ` sashiko-bot
2026-07-15 1:45 ` [PATCH v7 10/10] selftests: ftrace: Add wprobe trigger testcase Masami Hiramatsu (Google)
2026-07-15 2:16 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260715015741.1394D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.