On Tue, Sep 09, 2025 at 02:52:36PM -0400, Steven Rostedt wrote: > On Tue, 9 Sep 2025 14:39:48 -0400 > Steven Rostedt <[email protected]> wrote: > > > But anyway, I think it should work for the remote buffers too. Let me go > > and fix the current iterator. > > I thought it was broken but it isn't ;-) I did it properly, I just didn't > look deep enough. > > So yeah, look at the rb_iter_head_event() code. The ring buffer iterator > has a copy of the event. It has: > > if ((iter->head + length) > commit || length > iter->event_size) > /* Writer corrupted the read? */ > goto reset; > > memcpy(iter->event, event, length); > /* > * If the page stamp is still the same after this rmb() then the > * event was safely copied without the writer entering the page. > */ > smp_rmb(); > > /* Make sure the page didn't change since we read this */ > if (iter->page_stamp != iter_head_page->page->time_stamp || > commit > rb_page_commit(iter_head_page)) > goto reset; > > It first checks before copying that the data it's about to copy hasn't been > touched by the writer. > > It then copies the event into the iter->event temp buffer. > > Then it checks again that the data hasn't been touched. If it has, then > consider the data corrupt and end the iteration. This is how the "trace" > file works. I believe you could do the same for the remote code. > > If we are gonna keep the "trace" file, let's make sure it's fully > implemented.
I was more worry about the ring-buffer page order that can be reshuffled on each swap_reader_page(), making the page links useless in the kernel. Ideally, the meta-page would keep the page ID order somewhere. Alternatively, we could walk all the buffer pages to read the timestamp and re-create the order but that sounds quite cumbersome. > > -- Steve
