From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Shuah Khan <shuah@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Hari Bathini <hbathini@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 3/8] tracing: fprobe-events: Log error for exceeding the number of entry args
Date: Thu, 27 Feb 2025 07:10:45 +0900 [thread overview]
Message-ID: <20250227071045.7ead04fb9f467b0a7120c05a@kernel.org> (raw)
In-Reply-To: <20250226102223.586d7119@gandalf.local.home>
On Wed, 26 Feb 2025 10:22:23 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 26 Feb 2025 15:19:02 +0900
> "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
>
> > index 85f037dc1462..e27305d31fc5 100644
> > --- a/kernel/trace/trace_fprobe.c
> > +++ b/kernel/trace/trace_fprobe.c
> > @@ -1230,6 +1230,11 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> > if (is_return && tf->tp.entry_arg) {
> > tf->fp.entry_handler = trace_fprobe_entry_handler;
> > tf->fp.entry_data_size = traceprobe_get_entry_data_size(&tf->tp);
>
> Looking at traceprobe_get_entry_data_size(), the setting of the offset and
> what it returns is a bit of magic. It's not intuitive and really could use
> some comments. This isn't against this patch, but it does make it hard to
> review this patch.
Indeed. It is a bit tricky.
>
> > + if (ALIGN(tf->fp.entry_data_size, sizeof(long)) > MAX_FPROBE_DATA_SIZE) {
> > + trace_probe_log_set_index(2);
> > + trace_probe_log_err(0, TOO_MANY_EARGS);
> > + return -E2BIG;
> > + }
> > }
> >
> > ret = traceprobe_set_print_fmt(&tf->tp,
>
>
> We have this in trace_probe.c:
>
> static int __store_entry_arg(struct trace_probe *tp, int argnum)
> {
> struct probe_entry_arg *earg = tp->entry_arg;
> bool match = false;
> int i, offset;
>
> if (!earg) {
> earg = kzalloc(sizeof(*tp->entry_arg), GFP_KERNEL);
> if (!earg)
> return -ENOMEM;
> earg->size = 2 * tp->nr_args + 1;
> earg->code = kcalloc(earg->size, sizeof(struct fetch_insn),
> GFP_KERNEL);
> if (!earg->code) {
> kfree(earg);
> return -ENOMEM;
> }
> /* Fill the code buffer with 'end' to simplify it */
> for (i = 0; i < earg->size; i++)
> earg->code[i].op = FETCH_OP_END;
> tp->entry_arg = earg;
> }
>
> offset = 0;
> for (i = 0; i < earg->size - 1; i++) {
> switch (earg->code[i].op) {
> case FETCH_OP_END:
> earg->code[i].op = FETCH_OP_ARG;
> earg->code[i].param = argnum;
> earg->code[i + 1].op = FETCH_OP_ST_EDATA;
> earg->code[i + 1].offset = offset;
>
> // There's definitely some dependency between FETCH_OP_END, FETCH_OP_ARG
> // and FETCH_OP_ST_EDATA that isn't documented. At least not in this file.
This accumurates the fetching operation on the code. The problem is
limitation of the entry data size. So this scans the entry code and
checks whether the specified function argument is already stored, and
reuse it (return the offset where it is stored). If there isn't,
it stores a pair of FETCH_OP_ARG + FETCH_OP_ST_EDATA at the end of
the code array.
>
> return offset;
> case FETCH_OP_ARG:
> match = (earg->code[i].param == argnum);
> break;
> case FETCH_OP_ST_EDATA:
> offset = earg->code[i].offset;
> if (match)
> return offset;
> offset += sizeof(unsigned long);
> break;
> default:
> break;
> }
> }
> return -ENOSPC;
> }
>
> int traceprobe_get_entry_data_size(struct trace_probe *tp)
> {
> struct probe_entry_arg *earg = tp->entry_arg;
> int i, size = 0;
>
> if (!earg)
> return 0;
>
> for (i = 0; i < earg->size; i++) {
> switch (earg->code[i].op) {
> case FETCH_OP_END:
> goto out;
> case FETCH_OP_ST_EDATA:
> size = earg->code[i].offset + sizeof(unsigned long);
>
> // What makes earg->code[i].offset so special?
> // What is the guarantee that code[i + 1].offset is greater than code[i].offset?
> // I guess the above function guarantees that, but it's not obvious here.
Yeah, let me explain.
/*
* earg->code[] array has an operation sequence which is run in
* the entry handler.
* The sequence stopped by FETCH_OP_END and each data stored in
* the entry data buffer by FETCH_OP_ST_EDATA. The FETCH_OP_ST_EDATA
* stores the data at the data buffer + its offset, and all data are
* "unsigned long" size. The offset must be increased when a data is
* stored. Thus we need to find the last FETCH_OP_ST_EDATA in the
* code array.
*/
>
> break;
> default:
> break;
> }
> }
> out:
> return size;
> }
>
> Assuming that traceprobe_get_entry_data_size() does properly return the max size.
Yes, maybe we can scan the code array from the end for optimization but it still
needs the explanation.
>
> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Thank you!
>
> -- Steve
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2025-02-26 22:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 6:18 [PATCH 0/8] tracing: probes: Fixes and enhancing error logs Masami Hiramatsu (Google)
2025-02-26 6:18 ` [PATCH 1/8] tracing: tprobe-events: Fix a memory leak when tprobe with $retval Masami Hiramatsu (Google)
2025-02-26 15:09 ` Steven Rostedt
2025-02-26 6:18 ` [PATCH 2/8] tracing: tprobe-events: Reject invalid tracepoint name Masami Hiramatsu (Google)
2025-02-26 15:10 ` Steven Rostedt
2025-02-26 15:50 ` Markus Elfring
2025-02-26 6:19 ` [PATCH 3/8] tracing: fprobe-events: Log error for exceeding the number of entry args Masami Hiramatsu (Google)
2025-02-26 15:22 ` Steven Rostedt
2025-02-26 22:10 ` Masami Hiramatsu [this message]
2025-02-26 6:19 ` [PATCH 4/8] tracing: probe-events: Log errro for exceeding the number of arguments Masami Hiramatsu (Google)
2025-02-26 15:29 ` Steven Rostedt
2025-02-26 16:13 ` Markus Elfring
2025-02-27 0:19 ` Masami Hiramatsu
2025-02-27 10:13 ` [4/8] " Markus Elfring
2025-03-03 2:17 ` [PATCH 4/8] " Masami Hiramatsu
2025-02-26 6:19 ` [PATCH 5/8] tracing: probe-events: Remove unused MAX_ARG_BUF_LEN macro Masami Hiramatsu (Google)
2025-02-26 15:32 ` Steven Rostedt
2025-02-26 6:19 ` [PATCH 6/8] selftests/ftrace: Expand the tprobe event test to check wrong format Masami Hiramatsu (Google)
2025-02-26 6:19 ` [PATCH 7/8] selftests/ftrace: Add new syntax error test Masami Hiramatsu (Google)
2025-02-26 6:19 ` [PATCH 8/8] selftests/ftrace: Add dynamic events argument limitation test case Masami Hiramatsu (Google)
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=20250227071045.7ead04fb9f467b0a7120c05a@kernel.org \
--to=mhiramat@kernel.org \
--cc=hbathini@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).