[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130911174902.GA23532@Krystal>
Date: Wed, 11 Sep 2013 13:49:02 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: John Stultz <john.stultz@...aro.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Prarit Bhargava <prarit@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
lttng-dev@...ts.lttng.org
Subject: Re: [RFC PATCH] timekeeping: introduce timekeeping_is_busy()
Hi John,
* John Stultz (john.stultz@...aro.org) wrote:
> On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
> > Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
> > "timekeeping: Hold timekeepering locks in do_adjtimex and hardpps"
> > (3.10 kernels), the xtime write seqlock is held across calls to
> > __do_adjtimex(), which includes a call to notify_cmos_timer(), and hence
> > schedule_delayed_work().
> >
> > This introduces a side-effect for a set of tracepoints, including mainly
> > the workqueue tracepoints: a tracer hooking on those tracepoints and
> > reading current time with ktime_get() will cause hard system LOCKUP such
> > as:
> Oh bummer. I had just worked this issue out the other day:
> https://lkml.org/lkml/2013/9/9/476
>
> Apparently it was a schroedinbug of sorts. My apologies for time you
> spent chasing this down.
No worries. As soon as I've been able to reproduce it on my test box
(with serial port), the NMI watchdog had a pretty reasonable explanation
for the issue.
> My plan is to pull the notify_cmos_timer call to outside of the
> timekeeper locking (see the patch at the very end of the mail in the
> above link), as well as try to add lockdep support to seqcount/seqlocks
> so we can catch these sorts of issues more easily.
I just tried your patch, and it indeed seems to fix the lockup I've been
experiencing with lttng-modules. Do you plan pushing this fix into
master, and submitting it for inclusion into stable 3.10 and stable 3.11 ?
I'm planning on dealing with with this issue with a blacklist of
kernel versions that will prevent people from building lttng-modules
against broken kernels as soon as the patch makes it into those trees.
I will reply to the rest of your email separately, so this thread can
focus on getting the fix upstream quickly.
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists