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]

Message-ID: <20090820185344.1c0e48f8@skybase>
Date:	Thu, 20 Aug 2009 18:53:44 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Ingo Molnar <mingo@...e.hu>,
	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)

On Thu, 20 Aug 2009 18:14:07 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> wrote:

> On Thu, 20 Aug 2009, Martin Schwidefsky wrote:
> > On Thu, 20 Aug 2009 11:58:21 +0200
> > > 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.
> > 
> > We could use that time managment kernel thread for the watchdog
> > downgrade as well. Dunno if it is worth to create another kernel thread
> > that just sits there doing nothing for 99.9% of the time.
> > 
> > As for the fix: my brains starts to hurt looking at the pit clocksource
> > code. Why does it set CLOCK_EVT_FEAT_ONESHOT but then unregisters the
> > clocksource when the mode is set to CLOCK_EVT_MODE_ONESHOT?? That does
> > not make any sense to me. I would have expected that the pit does not
> > set CLOCK_EVT_MODE_ONESHOT. The timekeeping code wouldn't try use the
> > clock for one-shot if the bit is not set. And to unregister the clock
> > only because the mode is set to shutdown or unused doesn't seem to be
> > necessary either. My fix would be to remove the CLOCK_EVT_MODE_ONESHOT
> > bit from the features mask and to remove the clocksource_unregister
> > from the set_mode callback.
> 
> No. On UP machines we can run in oneshot mode with the PIT. 
> 
> The disable PIT clocksource hack was done in commit
> 1a0c009ac53de4a7664a1239936f0bc258133156. Yes, in hindsight we should
> have done 3f68535adad8dd89499505a65fb25d0e02d118cc in the first place.
> 
> So now the simple and correct fix is to remove the unregister call.

Sorry if I don't see the obvious but how can that work? If the pit as
clocksource is switched to CLOCK_EVT_MODE_ONESHOT it simply vanishes.
How is it possible that a UP machine runs with the PIT in oneshot mode?

And yes, hindsight is easier than foresight.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
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/