From: Steven Rostedt <rostedt@goodmis.org>
To: linux-trace-devel@vger.kernel.org
Cc: "Steven Rostedt (Google)" <rostedt@goodmis.org>
Subject: [PATCH 0/3] libtracecmd: Fix iterators
Date: Thu, 11 Jan 2024 17:15:35 -0500 [thread overview]
Message-ID: <20240111222201.154686-1-rostedt@goodmis.org> (raw)
From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
The iterators had three issues.
1) It used handle->max_cpu instead of handle->cpus
max_cpu is the max CPU number that was traced. But if a CPU had no data,
it was not included in the handle->cpu_data[] array, which is the
size of handle->cpus. The loop over the cpu_data[] array in the iterators
stopped at max_cpu and not cpus meaning it could overflow if one of the
CPUs had no tracing data.
2) There's no reason to free the records at the end of the iterator.
Not sure why that was done, but it was likely due to another bug that
was fixed. That freeing just fixed a symptom and not the issue.
Remove the freeing.
3) The next record for each of the CPUs was cached in a records[] array,
and when the next record to use was found, it would use that record
from the records[] array. The issue is if the callback called
tracecmd_read_data() on any of those records, it would invalidate the
one returned by "peek". Since the iterator does not know what the
callback might have done, it would have to refresh all the cached
records after each call to the callback() function.
Instead, just save the timestamps of the records for each CPU, and pick
the CPU with the next timestamp. Do the tracecmd_peek_data() on that
CPU and make sure it still matches the given timestamp. If it does not,
then try again.
Steven Rostedt (Google) (3):
libtracecmd: Use cpu_data[cpu]->cpus and not ->max_cpu
libtracecmd: Do not free records at end of iterator
libtracecmd: Just save timestamps and not the records in iterators
lib/trace-cmd/trace-input.c | 133 ++++++++++++------------------------
1 file changed, 45 insertions(+), 88 deletions(-)
--
2.43.0
next reply other threads:[~2024-01-11 22:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 22:15 Steven Rostedt [this message]
2024-01-11 22:15 ` [PATCH 1/3] libtracecmd: Use cpu_data[cpu]->cpus and not ->max_cpu Steven Rostedt
2024-01-11 22:15 ` [PATCH 2/3] libtracecmd: Do not free records at end of iterator Steven Rostedt
2024-01-11 22:15 ` [PATCH 3/3] libtracecmd: Just save timestamps and not the records in iterators Steven Rostedt
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=20240111222201.154686-1-rostedt@goodmis.org \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.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 read-only IMAP folder(s) and NNTP newsgroup(s).