From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] tracing: fprobe-events: Register fprobe-events only when it is enabled
Date: Wed, 26 Mar 2025 06:56:05 +0900 [thread overview]
Message-ID: <20250326065605.f2ba50780414fb9ba1110ab5@kernel.org> (raw)
In-Reply-To: <20250325144111.48fc4ec3@gandalf.local.home>
On Tue, 25 Mar 2025 14:41:11 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sun, 16 Mar 2025 21:21:42 +0900
> "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
>
> > From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> >
> > Currently fprobe events are registered when it is defined. Thus it will
> > give some overhead even if it is disabled. This changes it to register the
> > fprobe only when it is enabled.
> >
> > Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> > Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > ---
> > include/linux/fprobe.h | 8 +
> > kernel/trace/fprobe.c | 29 +++--
> > kernel/trace/trace_fprobe.c | 234 +++++++++++++++++++++----------------------
> > 3 files changed, 140 insertions(+), 131 deletions(-)
> >
> > diff --git a/include/linux/fprobe.h b/include/linux/fprobe.h
> > index 702099f08929..9635a24d5a25 100644
> > --- a/include/linux/fprobe.h
> > +++ b/include/linux/fprobe.h
> > @@ -94,6 +94,8 @@ int register_fprobe_ips(struct fprobe *fp, unsigned long *addrs, int num);
> > int register_fprobe_syms(struct fprobe *fp, const char **syms, int num);
> > int unregister_fprobe(struct fprobe *fp);
> > bool fprobe_is_registered(struct fprobe *fp);
> > +int fprobe_alloc_ip_list_from_filter(const char *filter, const char *notfilter,
> > + unsigned long **addrs);
> > #else
> > static inline int register_fprobe(struct fprobe *fp, const char *filter, const char *notfilter)
> > {
> > @@ -115,6 +117,12 @@ static inline bool fprobe_is_registered(struct fprobe *fp)
> > {
> > return false;
> > }
> > +static inline int fprobe_alloc_ip_list_from_filter(const char *filter,
> > + const char *notfilter,
> > + unsigned long **addrs)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > #endif
> >
> > /**
> > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c
> > index 33082c4e8154..05050f1c2239 100644
> > --- a/kernel/trace/fprobe.c
> > +++ b/kernel/trace/fprobe.c
> > @@ -486,6 +486,24 @@ static int ip_list_from_filter(const char *filter, const char *notfilter,
> > return match.index ?: -ENOENT;
> > }
> >
> > +#define FPROBE_IPS_MAX INT_MAX
> > +
> > +int fprobe_alloc_ip_list_from_filter(const char *filter, const char *notfilter,
> > + unsigned long **addrs)
> > +{
> > + int ret;
> > +
> > + /* Count the number of ips from filter. */
> > + ret = ip_list_from_filter(filter, notfilter, NULL, FPROBE_IPS_MAX);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *addrs = kcalloc(ret, sizeof(unsigned long), GFP_KERNEL);
> > + if (!*addrs)
> > + return -ENOMEM;
> > + return ip_list_from_filter(filter, notfilter, *addrs, ret);
>
> This was in the old code, but I'm wondering. Does this code prevent modules
> from being loaded and unloaded too?
Ah, no. In that case we should do module_get() for each module
found in module_kallsyms_on_each_symbol(), hmm.
>
> I'm asking because if we call the first instance of ip_list_from_filter()
> and it finds a list of functions from a module, and then that module is
> unloaded, the ip_list_from_filter() will return a failure, and *addrs would
> be a memory leak.
Good catch! Let me fix it.
Thanks,
>
> -- Steve
>
> > +}
> > +
> > static void fprobe_fail_cleanup(struct fprobe *fp)
> > {
> > kfree(fp->hlist_array);
> > @@ -528,8 +546,6 @@ static int fprobe_init(struct fprobe *fp, unsigned long *addrs, int num)
> > return 0;
> > }
> >
> > -#define FPROBE_IPS_MAX INT_MAX
> > -
> > /**
> > * register_fprobe() - Register fprobe to ftrace by pattern.
> > * @fp: A fprobe data structure to be registered.
> > @@ -549,14 +565,7 @@ int register_fprobe(struct fprobe *fp, const char *filter, const char *notfilter
> > if (!fp || !filter)
> > return -EINVAL;
> >
> > - ret = ip_list_from_filter(filter, notfilter, NULL, FPROBE_IPS_MAX);
> > - if (ret < 0)
> > - return ret;
> > -
> > - addrs = kcalloc(ret, sizeof(unsigned long), GFP_KERNEL);
> > - if (!addrs)
> > - return -ENOMEM;
> > - ret = ip_list_from_filter(filter, notfilter, addrs, ret);
> > + ret = fprobe_alloc_ip_list_from_filter(filter, notfilter, &addrs);
> > if (ret > 0)
> > ret = register_fprobe_ips(fp, addrs, ret);
> >
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2025-03-25 21:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-16 12:21 [PATCH 0/4] tracing: fprobe-events: Register fprobe only when the event is enabled Masami Hiramatsu (Google)
2025-03-16 12:21 ` [PATCH 1/4] tracing: tprobe-events: Remove mod field from tprobe-event Masami Hiramatsu (Google)
2025-03-16 12:21 ` [PATCH 2/4] tracing: tprobe-events: Support multiple tprobes on the same tracepoint Masami Hiramatsu (Google)
2025-03-25 17:06 ` Steven Rostedt
2025-03-25 22:08 ` Masami Hiramatsu
2025-03-29 13:35 ` Masami Hiramatsu
2025-03-16 12:21 ` [PATCH 3/4] tracing: fprobe-events: Register fprobe-events only when it is enabled Masami Hiramatsu (Google)
2025-03-25 18:41 ` Steven Rostedt
2025-03-25 21:56 ` Masami Hiramatsu [this message]
2025-03-16 12:21 ` [PATCH 4/4] selftests: tracing: Enable fprobe events before checking enable_functions Masami Hiramatsu (Google)
2025-03-25 18:42 ` Steven Rostedt
2025-03-25 21:47 ` Masami Hiramatsu
2025-03-17 8:03 ` [RFC PATCH] tracing: tprobe-events: Register tracepoint when enable tprobe event Masami Hiramatsu (Google)
2025-03-17 8:10 ` Masami Hiramatsu
2025-05-01 15:27 ` Steven Rostedt
2025-05-09 23:41 ` Masami Hiramatsu
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=20250326065605.f2ba50780414fb9ba1110ab5@kernel.org \
--to=mhiramat@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
/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.