* Re: [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust
[not found] ` <20260502181619.7f5003dc@robin>
@ 2026-05-07 4:14 ` Masami Hiramatsu
2026-05-11 16:29 ` Steven Rostedt
0 siblings, 1 reply; 2+ messages in thread
From: Masami Hiramatsu @ 2026-05-07 4:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
On Sat, 2 May 2026 18:17:06 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> On Sat, 2 May 2026 15:23:04 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > Hi Masami,
> >
> > I applied your patches and enabled your ptracingtest code. I noticed
> > that when there's dropped pages, the trace output is not in order:
> >
> > # trace-cmd start -B ptracingtest -e all -v -e '*lock*'
> > # taskset -c 5 echo c > /proc/sysrq-trigger
> >
> > On reboot, I ran:
> >
> > # trace-cmd show -B ptracingtest > /tmp/trace.out
> >
> > Then executed the attached perl program:
> >
> > # ./read-ts.pl < /tmp/trace.out
> >
> > And it errors our:
> >
> > 30.212495 < 30.213534
> > <...>-1048 [005] d.... 30.212495: irq_enable: caller=irqentry_exit+0xf5/0x710 parent=0x0
> >
> > That is, I think the zero timestamps may be messing with the order.
> >
>
> Ah, I think I found the problem. The iterator needs the same logic you
> added for the consuming read:
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 7bfbed0ac90c..90a7fa772fe3 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -6105,12 +6105,14 @@ rb_iter_peek(struct ring_buffer_iter *iter, u64 *ts)
> struct ring_buffer_per_cpu *cpu_buffer;
> struct ring_buffer_event *event;
> int nr_loops = 0;
> + int max_loops;
>
> if (ts)
> *ts = 0;
>
> cpu_buffer = iter->cpu_buffer;
> buffer = cpu_buffer->buffer;
> + max_loops = cpu_buffer->ring_meta ? cpu_buffer->nr_pages : 3;
>
> /*
> * Check if someone performed a consuming read to the buffer
> @@ -6133,7 +6135,7 @@ rb_iter_peek(struct ring_buffer_iter *iter, u64 *ts)
> * the ring buffer with an active write as the consumer is.
> * Do not warn if the three failures is reached.
> */
> - if (++nr_loops > 3)
> + if (++nr_loops > max_loops)
> return NULL;
>
> if (rb_per_cpu_empty(cpu_buffer))
>
>
> I'll test this some more, and make a proper patch.
Ah, indeed. Thanks for fixing!
BTW, shouldn't we unify common logic of those functions?
Thank you,
>
> -- Steve
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust
2026-05-07 4:14 ` [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust Masami Hiramatsu
@ 2026-05-11 16:29 ` Steven Rostedt
0 siblings, 0 replies; 2+ messages in thread
From: Steven Rostedt @ 2026-05-11 16:29 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
On Thu, 7 May 2026 13:14:16 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > I'll test this some more, and make a proper patch.
>
> Ah, indeed. Thanks for fixing!
>
> BTW, shouldn't we unify common logic of those functions?
Hmm, there's not much common between the two. One is a consuming read and
the other is a non-consuming read that needs to test for a bunch of race
conditions.
If you see something that can be shared, I'm all for it.
-- Steve
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-11 16:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <177751968499.2136606.17388366710182662849.stgit@mhiramat.tok.corp.google.com>
[not found] ` <20260502152304.560a5954@robin>
[not found] ` <20260502181619.7f5003dc@robin>
2026-05-07 4:14 ` [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust Masami Hiramatsu
2026-05-11 16:29 ` Steven Rostedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox