From: Jason Baron <jbaron@redhat.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
2nddept-manager@sdl.hitachi.co.jp
Subject: Re: [PATCH][GIT PULL] tracing: Fix compile issue for trace_sched_wakeup.c
Date: Thu, 21 Oct 2010 10:00:31 -0400 [thread overview]
Message-ID: <20101021140031.GC2920@redhat.com> (raw)
In-Reply-To: <4CBFAC70.30602@hitachi.com>
On Thu, Oct 21, 2010 at 11:58:56AM +0900, Masami Hiramatsu wrote:
> (2010/10/21 1:43), Jason Baron wrote:
> > On Wed, Oct 20, 2010 at 05:40:45PM +0200, Ingo Molnar wrote:
> >> FYI, there's a new mystery hang (sometimes crash) that triggers in -tip - and which
> >> seems to be tracing related. See the crashlog below - config attached.
> >>
> >> It's not bisectable - small changes in the kernel make the bug come/go. (might be a
> >> race of some sorts)
> >>
> >> Thanks,
> >>
> >> Ingo
> >>
> >
> > strange b/c it looks like we get though enabling/disabling the
> > tracepoitns individually, but then when we go to enable all the
> > tracepoints we hit this hang - perhaps, suggesting a race. Do we always
> > fail after "Testing all events:" is printed? Does the crash have any
> > more clues. I will try and re-produce this.
> >
> > Also, I noticed some recent changes to text_poke_smp() usage of
> > stop_machine() on Oct. 14th. That's related to the area where this appears
> > to hang, so if things were working with this .config before then, that
> > might be a place to look. Adding Masami to the 'cc list.
>
> Recent changes of text_poke_smp() just removed unnecessary
> get/put_online_cpu(), so I think it's not related this bug.
>
> It seems there can be a bug in stop_machine() routine under
> heavy use. usually that is called just once at a time, but jump
> label and optprobe might call it heavily (thousands times?).
> So some racy situation can be happen easily.
>
for most tracepoints there is 1 text location that needs to be
updated...however, I know that for kmalloc, you can end up with
hundredds or even thousands. So yes, we can end up calling
stop_machine() thousands of times.
There is a patch to reduce kmalloc tracepoint text locations by moving
them out of line: http://lkml.org/lkml/2010/10/13/208
Also, text_poke_smp_batch() would allow us to update all these text
locations at once.
Nonetheless, there appears to be a underlying race condition...
thanks,
-Jason
next prev parent reply other threads:[~2010-10-21 14:01 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 17:11 [PATCH][GIT PULL] tracing: Fix compile issue for trace_sched_wakeup.c Steven Rostedt
2010-10-19 18:41 ` Ingo Molnar
2010-10-20 15:40 ` Ingo Molnar
2010-10-20 16:37 ` Steven Rostedt
2010-10-20 18:40 ` Ingo Molnar
2010-10-20 16:43 ` Jason Baron
2010-10-20 18:33 ` Ingo Molnar
2010-10-21 11:09 ` Ingo Molnar
2010-10-22 17:58 ` Jason Baron
2010-10-22 18:24 ` Ingo Molnar
2010-10-22 18:39 ` Jason Baron
2010-10-23 20:02 ` Ingo Molnar
2010-10-24 0:53 ` Steven Rostedt
2010-10-24 11:25 ` Ingo Molnar
2010-10-25 8:59 ` Ingo Molnar
2010-10-25 9:30 ` Ingo Molnar
2010-10-25 11:45 ` Ingo Molnar
2010-10-25 12:10 ` Ingo Molnar
2010-10-25 12:18 ` Peter Zijlstra
2010-10-25 12:32 ` Ingo Molnar
2010-10-25 15:47 ` Peter Zijlstra
2010-10-25 16:07 ` Peter Zijlstra
2010-10-25 17:25 ` Ingo Molnar
2010-10-25 17:32 ` Ingo Molnar
2010-10-25 17:45 ` Peter Zijlstra
2010-10-25 17:52 ` Jason Baron
2010-10-30 10:42 ` [tip:perf/urgent] jump label: Add work around to i386 gcc asm goto bug tip-bot for Steven Rostedt
2010-10-25 15:55 ` [PATCH][GIT PULL] tracing: Fix compile issue for trace_sched_wakeup.c Jason Baron
2010-10-25 16:09 ` Peter Zijlstra
2010-10-22 21:42 ` Jason Baron
2010-10-23 4:41 ` Steven Rostedt
2010-10-21 2:58 ` Masami Hiramatsu
2010-10-21 7:22 ` Peter Zijlstra
2010-10-21 11:01 ` Steven Rostedt
2010-10-21 11:03 ` Peter Zijlstra
2010-10-21 12:45 ` Steven Rostedt
2010-10-21 13:50 ` Jason Baron
2010-10-22 4:56 ` Masami Hiramatsu
2010-10-21 14:00 ` Jason Baron [this message]
2010-10-21 11:14 ` Steven Rostedt
2010-10-21 11:26 ` Ingo Molnar
2010-10-21 13:55 ` Jason Baron
2010-10-21 14:43 ` Ingo Molnar
2010-10-22 1:44 ` Jason Baron
2010-10-22 8:14 ` Peter Zijlstra
2010-10-22 14:13 ` Jason Baron
2010-10-22 14:23 ` Peter Zijlstra
2010-10-22 14:36 ` Steven Rostedt
2010-10-22 14:36 ` Jason Baron
2010-10-22 8:16 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101021140031.GC2920@redhat.com \
--to=jbaron@redhat.com \
--cc=2nddept-manager@sdl.hitachi.co.jp \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.