All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: [PATCH] trace-cmd library: Have tracecmd_iterate_events() start where it left off
Date: Thu, 15 Jun 2023 13:12:16 -0400	[thread overview]
Message-ID: <20230615131216.1fc36f0f@gandalf.local.home> (raw)

From: "Steven Rostedt (Google)" <rostedt@goodmis.org>

When a callback to tracecmd_iterate_events() returns non-zero, it exits
the iteration. Allow a sequential call to tracecmd_iterate_events() to
start were it left off.

The iterator peeks at the data which needs to be cleared. But the peek
itself set the next read to be the next record. On a sequential iterator
call, it will not include the cached records that were left over from the
previous iterator call.

Make sure at the end of the iterator to reset the indexes so that the next
reads will be the recorders that were not processed by the iterator.

Also do the same for tracecmd_iterate_events_multi() and remove the stale
comment about not needing to free the records.

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
 lib/trace-cmd/trace-input.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/lib/trace-cmd/trace-input.c b/lib/trace-cmd/trace-input.c
index 51420c13c750..5279f581439d 100644
--- a/lib/trace-cmd/trace-input.c
+++ b/lib/trace-cmd/trace-input.c
@@ -2820,10 +2820,15 @@ int tracecmd_iterate_events(struct tracecmd_input *handle,
 
 	/* Need to unlock and free the records */
 	for (cpu = 0; cpu < handle->max_cpu; cpu++) {
+		int offset;
+
 		if (!records[cpu])
 			continue;
-		record = tracecmd_read_data(handle, cpu);
-		tracecmd_free_record(record);
+
+		offset = (int)(records[cpu]->offset & (handle->page_size - 1));
+		free_next(handle, cpu);
+		/* Reset the buffer to read the cached record again */
+		kbuffer_read_at_offset(handle->cpu_data[cpu].kbuf, offset, NULL);
 	}
 
 	free(records);
@@ -2917,20 +2922,20 @@ int tracecmd_iterate_events_multi(struct tracecmd_input **handles,
 	/* Unlock and free the records */
 	for (cpu = 0; cpu < all_cpus; cpu++) {
 		int local_cpu;
+		int offset;
 
 		if (!records[cpu].record)
 			continue;
 
 		handle = records[cpu].handle;
 		local_cpu = cpu - handle->start_cpu;
-		record = tracecmd_read_data(handle, local_cpu);
-		tracecmd_free_record(record);
+
+		offset = (int)(records[cpu].record->offset & (handle->page_size - 1));
+		free_next(handle, local_cpu);
+		/* Reset the buffer to read the cached record again */
+		kbuffer_read_at_offset(handle->cpu_data[cpu].kbuf, offset, NULL);
 	}
 
-	/*
-	 * The records array contains only records that were taken via
-	 * tracecmd_peek_data(), and do not need to be freed.
-	 */
 	free(records);
 
 	return ret;
-- 
2.39.2


                 reply	other threads:[~2023-06-15 17:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20230615131216.1fc36f0f@gandalf.local.home \
    --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 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.