From: Steven Rostedt <rostedt@goodmis.org>
To: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Cc: Vincent Donnefort <vdonnefort@google.com>
Subject: [PATCH v2] kbuffer: Update kbuf->next in kbuffer_refresh()
Date: Mon, 8 Jan 2024 12:38:59 -0500 [thread overview]
Message-ID: <20240108123859.32db3407@gandalf.local.home> (raw)
From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
If the kbuffer was read to completion, the kbuf->curr would equal both the
size and kbuf->next. The kbuffer_refresh() is to update the kbuf if more
data was added to the buffer. But if curr is at the end, the next pointer
was not updated, which is incorrect. The next pointer needs to be moved to
the end of the newly written event.
Update the pointers in kbuffer_refresh() just as if it was loaded new (but
still keeping curr at the correct location).
Fixes: 7a4d5b24 ("kbuffer: Add kbuffer_refresh() API")
Reported-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
Changes since v1: https://lore.kernel.org/linux-trace-devel/ZZfJQTOyl0dHiTU-@google.com/
- Use "next_event()" call and not just update_pointers() as if the next
event is an extended timestamp or absolute timestamp, it is not to be
returned to the user. The event that is attached to the timestamp is to
be returned. The next_event() will iterate until it gets to the event,
skipping over the time stamps.
src/kbuffer-parse.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/kbuffer-parse.c b/src/kbuffer-parse.c
index 691d53678f5f..48b578011a5a 100644
--- a/src/kbuffer-parse.c
+++ b/src/kbuffer-parse.c
@@ -180,6 +180,7 @@ static int calc_index(struct kbuffer *kbuf, void *ptr)
return (unsigned long)ptr - (unsigned long)kbuf->data;
}
+static int next_event(struct kbuffer *kbuf);
static int __next_event(struct kbuffer *kbuf);
/*
@@ -299,6 +300,9 @@ void kbuffer_free(struct kbuffer *kbuf)
free(kbuf);
}
+static unsigned int old_update_pointers(struct kbuffer *kbuf);
+static unsigned int update_pointers(struct kbuffer *kbuf);
+
/**
* kbuffer_refresh - update the meta data from the subbuffer
* @kbuf; The kbuffer to update
@@ -309,13 +313,20 @@ void kbuffer_free(struct kbuffer *kbuf)
int kbuffer_refresh(struct kbuffer *kbuf)
{
unsigned long long flags;
+ unsigned int old_size;
if (!kbuf || !kbuf->subbuffer)
return -1;
+ old_size = kbuf->size;
+
flags = read_long(kbuf, kbuf->subbuffer + 8);
kbuf->size = (unsigned int)flags & COMMIT_MASK;
+ /* Update next to be the next element */
+ if (kbuf->size != old_size && kbuf->curr == kbuf->next)
+ next_event(kbuf);
+
return 0;
}
--
2.43.0
reply other threads:[~2024-01-08 17:38 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=20240108123859.32db3407@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=vdonnefort@google.com \
/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.