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 <sv...@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
config.gz
Description: application/gzip
