linux-kernel - Re: [circular locking bug] Re: [patch 00/15] clocksource / timekeeping rework V4 (resend V3 + bug fix)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Aug 2009 11:58:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	john stultz <johnstul@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [circular locking bug] Re: [patch 00/15] clocksource /
	timekeeping rework V4 (resend V3 + bug fix)


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

> On Wed, 19 Aug 2009 22:25:54 +0200
> Ingo Molnar <mingo@...e.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
--
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/