linux-kernel - Re: BUG: cpufreq notification broken

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, 16 Nov 2006 15:27:23 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Thomas Gleixner <tglx@...esys.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...l.org>, Andi Kleen <ak@...e.de>
Subject: Re: BUG: cpufreq notification broken

On Thu, 16 Nov 2006, Thomas Gleixner wrote:

> [PATCH] cpufreq: make the transition_notifier chain use SRCU
> (b4dfdbb3c707474a2254c5b4d7e62be31a4b7da9)
> 
> breaks cpu frequency notification users, which register the callback on
> core_init level. Interestingly enough the registration survives the
> uninitialized head, but the registered user is lost by:
> 
> static int __init init_cpufreq_transition_notifier_list(void)
> {
> 	srcu_init_notifier_head(&cpufreq_transition_notifier_list);
> 	return 0;
> }
> core_initcall(init_cpufreq_transition_notifier_list);
> 
> This affects i386, x86_64 and sparc64 AFAICT, which call
> register_notifier early in the arch code.
> 
> > The head of the notifier chain needs to be initialized before use;
> > this is done by an __init routine at core_initcall time. If this turns
> > out not to be a good choice, it can easily be changed.
> 
> Hmm, there are no static initializers for srcu and the only way to fix
> this up is to move the arch calls to postcore_init.

If you can find a way to invoke init_cpufreq_transition_notifier_list 
earlier than core_initcall time, that would be okay.  I did it this way 
because it was easiest, but earlier should be just as good.

The only requirement is that alloc_percpu() has to be working, so that the 
SRCU per-cpu data values can be set up.  I don't know how early in the 
boot process you can do per-cpu memory allocation.

As an alternative approach, initialization of srcu_notifiers could be 
broken up into two pieces, one of which could be done statically.  The 
part that has to be done dynamically (the SRCU initialization) wouldn't 
mess up the notifier chain.  Provided the dynamic part is carried out 
while the system is still single-threaded, it would be safe.

Alan Stern

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