linux-kernel - Re: [patch 7/9] Adapt the time initialization code

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: <20070201134141.GO21755@dwarf.suse.cz>
Date:	Thu, 1 Feb 2007 14:41:43 +0100
From:	Jiri Bohac <jbohac@...e.cz>
To:	Andi Kleen <ak@...e.de>
Cc:	jbohac@...e.cz, linux-kernel@...r.kernel.org,
	Vojtech Pavlik <vojtech@...e.cz>, ssouhlal@...ebsd.org,
	arjan@...radead.org, tglx@...utronix.de, johnstul@...ibm.com,
	zippel@...ux-m68k.org, andrea@...e.de
Subject: Re: [patch 7/9] Adapt the time initialization code

On Thu, Feb 01, 2007 at 12:26:33PM +0100, Andi Kleen wrote:
> 
> > +extern void time_initialize_cpu(void);
> 
> Never put externs into .c files. Multiple occurrences.

Ok, will fix it, sorry.

> > +void time_initialize_cpu(void *info)
> > +{
> > +	unsigned long flags;
> > +	int cpu = smp_processor_id();
> 
> Are you sure this can never preempt? 

yes, preemption is explicitly disabled in start_secondary() that
calls this function.

> > +	/* FIXME: what speed does the cpu really start at; I doubt cpu_khz is right at this point ??!!!
> 
> It should be. It comes from measurements. Unless the CPU changes frequency
> behind the kernel's back, but there is nothing that can be done then.

Well, I'm not sure. I think the global variable cpu_khz is wrong
in the first place. This should be per-cpu, because each CPU can
have a different frequency, right?

And cpu_khz is adjusted in time_cpufreq_notifier() when whichever
CPU's frequency changes.  To me it seems that it's a leftover from
the times when all CPUs in a system ran at the same speed. I
think it should be killed. I just did not want to make too many
unrelated changes in one patchset.

It doesn't matter that much in this case that it probably is
wrong (as the comment explains)...

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, SUSE CZ

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