lkml.org 
[lkml]   [2009]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [circular locking bug] Re: [patch 00/15] clocksource / timekeeping rework V4 (resend V3 + bug fix)

* Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:

> On Wed, 19 Aug 2009 22:25:54 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> >
> > ok, with all the latest patches i re-added these bits to
> > -tip, and it triggered this lockdep assert on a testbox:
>
> Another one :-(
>
> > stack backtrace:
> > Pid: 1, comm: swapper Not tainted 2.6.31-rc6-tip-01234-gcc9be0e-dirty #1054
> > Call Trace:
> > [<c106f430>] print_usage_bug+0x130/0x180
> > [<c106f5eb>] mark_lock_irq+0x16b/0x260
> > [<c106f240>] ? check_usage_forwards+0x0/0xc0
> > [<c106f7fe>] mark_lock+0x11e/0x3a0
> > [<c106fbff>] mark_irqflags+0x17f/0x190
> > [<c107177a>] __lock_acquire+0x29a/0x520
> > [<c1071a6a>] lock_acquire+0x6a/0xc0
> > [<c10664d7>] ? clocksource_unregister+0x17/0x50
> > [<c175719b>] __mutex_lock_common+0x3b/0x340
> > [<c10664d7>] ? clocksource_unregister+0x17/0x50
> > [<c1757551>] mutex_lock_nested+0x31/0x40
> > [<c10664d7>] ? clocksource_unregister+0x17/0x50
> > [<c10664d7>] clocksource_unregister+0x17/0x50
> > [<c1008b3a>] pit_disable_clocksource+0x2a/0x40
> > [<c1008bb9>] init_pit_timer+0x29/0xb0
> > [<c106825a>] clockevents_set_mode+0x1a/0x50
> > [<c1069a96>] tick_switch_to_oneshot+0x96/0xc0
> > [<c1069ad2>] tick_init_highres+0x12/0x20
> > [<c105e32d>] hrtimer_switch_to_hres+0x4d/0x100
> > [<c105ebbd>] hrtimer_run_pending+0x4d/0x50
> > [<c104bb85>] run_timer_softirq+0x25/0x230
>
> Ok, the cause is that the i8253 pit clocksource code
> tries to unregister a clocksource from a timer
> interrupt. Bad idea with the new code. Why does the pit
> clocksource have to >unregister< the clock if the
> set_mode callback is called with
> CLOCK_EVT_MODE_SHUTODWN, CLOCK_EVT_MODE_UNUSED, or
> CLOCK_EVT_MODE_ONESHOT? Very strange, I would argue
> that the clocksource should never unregister in the
> set_mode callback, the timekeeping code should not use
> the clocksource if it is unsuitable for e.g. the one
> shot mode.

i think this 'execute timer management functions right
from the deep bowels of time events' concept is
fundamentally flawed and one big layering violation. It
caused numerous problems (lockups, etc.) in the past.

There should be a time management kernel thread instead
(or workqueue), which does a proper state machine of all
these properties - without having to call this stuff from
within a timer handler.

Ingo


\
 
 \ /
  Last update: 2009-08-20 12:01    [W:0.133 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site