linux-kernel - Re: [PATCH] clocksource: setup mult_orig in clocksource

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: <20090615200456.GA31202@linux-sh.org>
Date:	Tue, 16 Jun 2009 05:04:57 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	john stultz <johnstul@...ibm.com>
Cc:	Magnus Damm <magnus.damm@...il.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, tglx@...utronix.de, akpm@...ux-foundation.org
Subject: Re: [PATCH] clocksource: setup mult_orig in clocksource_enable()

On Mon, Jun 15, 2009 at 12:08:37PM -0700, john stultz wrote:
> On Sun, 2009-06-14 at 19:20 +0900, Magnus Damm wrote:
> > On Sat, Jun 13, 2009 at 8:56 AM, john stultz<johnstul@...ibm.com> wrote:
> > > On Thu, 2009-06-11 at 14:51 +0900, Magnus Damm wrote:
> > >> I can't think of any way that would work. The clock frequency can be
> > >> changed while the clock is disabled. And we can only know the rate
> > >> after enabling the clock, see these lines from include/linux/clk.h:
> > >>
> > >> /**
> > >>  * clk_get_rate - obtain the current clock rate (in Hz) for a clock source.
> > >>  *              This is only valid once the clock source has been enabled.
> > >>  * @clk: clock source
> > >>  */
> > >> unsigned long clk_get_rate(struct clk *clk);
> > >
> > > Hrmm.. Yuck.
> > >
> > > Is this really expected behavior that a clk would change frequencies
> > > between uses as a clocksource?
> > 
> > Yes, I think so. The clock frequency can change through cpufreq or
> > clk_set_rate().
> 
> But they do not change freq (through cpufreq or anything else) after the
> enable() call, right? That would be pretty critical. Otherwise they'd
> need to be disqualified like we do the TSC on x86.
> 
This is a bit tricky, the clock needs to be able to adjust its parent
divisors/multipliers in order to maintain its current frequency if a
parent clock changes frequency. We do not presently prohibit a frequency
change that deviates from the current frequency on these clocks, but
this would be trivially handled by setting a fixed rate flag for those
clocks. This sort of logic is necessary to block frequency changes in the
parent clock topology that would throw the child clock's frequency out of
sync. Note that in the general case we do not want to disable frequency
changes on enabled clocks, enabled clocks only need to know whether they
can handle a frequency change or not without destabilizing the system.

The only thing the usecount presently disables on an enabled clock is
reparenting it. ie, migrating between different parent PLLs while in
active use.

There is no fundamental limitation as with the TSC, we can have as much
or as little flexibility as we like.
--
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/