On Mon, 26 May 2025 12:03:42 +0900
Masami Hiramatsu (Google) <mhira...@kernel.org> wrote:
> On Fri, 23 May 2025 17:28:57 -0400
> Steven Rostedt <rost...@goodmis.org> wrote:
>
> > On Fri, 23 May 2025 16:54:25 -0400
> > Steven Rostedt <rost...@goodmis.org> wrote:
> >
> > > I think we also need this:
> > >
> > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > > index 7d837963dd1e..456efebc396a 100644
> > > --- a/kernel/trace/ring_buffer.c
> > > +++ b/kernel/trace/ring_buffer.c
> > > @@ -3638,6 +3638,9 @@ rb_move_tail(struct ring_buffer_per_cpu *cpu_buffer,
> > >
> > > rb_reset_tail(cpu_buffer, tail, info);
> > >
> > > + /* The new page should have zero committed */
> > > + rb_init_page(next_page->page);
> > > +
> > > /* Commit what we have for now. */
> > > rb_end_commit(cpu_buffer);
> > > /* rb_end_commit() decs committing */
> >
> > No we don't need it ;-)
> >
> > I'm looking deeper into the code and we have this:
> >
> > /*
> > * No need to worry about races with clearing out the commit.
> > * it only can increment when a commit takes place. But that
> > * only happens in the outer most nested commit.
> > */
> > local_set(&next_page->page->commit, 0);
> >
> > When the tail page gets moved.
>
> Yeah, when the page gets written, it is cleared.
What about this? It seems if we keep the reader->page->commit, when we
catch up the tail page, rb_get_reader_page() returns new reader (== tail)
because reader->read(==0) < reader->page->commit. But we should not return
new reader.
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 5034bae02f08..179142db9586 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -5522,6 +5522,12 @@ rb_get_reader_page(struct ring_buffer_per_cpu
*cpu_buffer)
cpu_buffer->last_overrun = overwrite;
}
+ /* But if we catch up to the tail, do not return reader page. */
+ if (cpu_buffer->commit_page == cpu_buffer->reader_page) {
+ reader = NULL;
+ goto out;
+ }
+
goto again;
out:
--
Masami Hiramatsu (Google) <mhira...@kernel.org>
