Messages in this thread | | | Date | Thu, 14 May 2020 08:09:14 +0200 | From | Sven Schnelle <> | Subject | Re: [tracing] 06e0a548ba: WARNING:at_kernel/trace/ring_buffer.c:#ring_buffer_iter_peek |
| |
Hi Steve,
On Wed, May 13, 2020 at 03:30:33PM -0400, Steven Rostedt wrote: > On Wed, 13 May 2020 18:15:57 +0200 > Sven Schnelle <svens@linux.ibm.com> wrote: > > > Thanks for looking into this. I've attached my /proc/config.gz to this Mail. > > The x86 system is my Laptop which is a Thinkpad X280 with 4 HT CPUs (so 8 cpus > > in total). I've tried disabling preemption, but this didn't help. > > > > It's always this check that causes the loop: > > > > if (iter->head >= rb_page_size(iter->head_page)) { > > rb_inc_iter(iter); > > goto again; > > } > > > > On the first loop iter->head is some value > 0 and rb_page_size returns > > 0, afterwards it gets twice to this check with both values 0. The third > > time the warning is triggered. Maybe that information helps. > > I figured out what was causing this, and that's just that the writer and > the iterator could end up almost "in sync" where the writer writes to each > of the pages the iterator is trying to read, and this can trigger the three > failures of "zero commits" per page. > > I had a way to detect this, but then realized that it may be possible for > an active writer to possibly trigger the other failures to get an event, > that I just decided to force it to try three times, and simply return NULL > if an active writer is messing with the iterator. The iterator is a "best > effort" to read the buffer if there's an active writer. The consumer read > (trace_pipe) is made for that. > > This patch should solve you issues. > > (care to give a Tested-by: if it works for you?)
Well, as there's no longer a RB_WARN_ON that indeed fixes the issue :-)
Tested-by: Sven Schnelle <svens@linux.ibm.com>
Thanks!
Sven
| |