Re: [tracing] 06e0a548ba: WARNING:at_kernel/trace/ring_buffer.c:#ring_buffer_iter_peek

[Sven Schnelle <svens@linux.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

Hi Steve,

On Wed, May 13, 2020 at 09:29:22AM -0400, Steven Rostedt wrote:
> On Wed, 13 May 2020 11:19:06 +0200
> Sven Schnelle <svens@linux.ibm.com> wrote:
> 
> > Did you had a chance to look into this? I can easily reproduce this both on x86
> > and s390 by doing:
> > 
> > cd /sys/kernel/tracing
> > cat /dev/zero >/dev/null & # generate some load
> > echo function >current_tracer
> > # wait a few seconds to fill the buffer
> > cat trace
> > 
> > Usually it will print the warn after a few seconds.
> > 
> > I haven't digged through all the ring buffer code yet, so i thought i might ask
> > whether you have an idea what's going on.
> 
> Can you send me the config for where you can reproduce it on x86?
> 
> The iterator now doesn't stop the ring buffer when it iterates, and is
> doing so over a live buffer (but should be able to handle it). It's
> triggering something I thought wasn't suppose to happen (which must be
> happening).
> 
> Perhaps with your config I'd be able to reproduce it.

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.

Thanks,
Sven

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 29532 bytes --]