linux-kernel - Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall

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:	Fri, 17 Nov 2006 21:57:46 -0800
From:	"Paul E. McKenney" <paulmck@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Linus Torvalds <torvalds@...l.org>,
	Thomas Gleixner <tglx@...esys.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	john stultz <johnstul@...ibm.com>,
	David Miller <davem@...emloft.net>,
	Arjan van de Ven <arjan@...radead.org>,
	Andi Kleen <ak@...e.de>, manfred@...orfullife.com,
	oleg@...sign.ru
Subject: Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync

On Fri, Nov 17, 2006 at 08:51:03PM -0800, Andrew Morton wrote:
> On Fri, 17 Nov 2006 23:33:45 -0500 (EST)
> Alan Stern <stern@...land.harvard.edu> wrote:
> 
> > On Fri, 17 Nov 2006, Paul E. McKenney wrote:
> >
> > > > Perhaps a better approach to the initialization problem would be to assume
> > > > that either:
> > > >
> > > >     1.  The srcu_struct will be initialized before it is used, or
> > > >
> > > >     2.  When it is used before initialization, the system is running
> > > > 	only one thread.
> > >
> > > Are these assumptions valid?  If so, they would indeed simplify things
> > > a bit.
> >
> > I don't know.  Maybe Andrew can tell us -- is it true that the kernel runs
> > only one thread up through the time the core_initcalls are finished?
> 
> I don't see why - a core_initcall could go off and do the
> multithreaded-pci-probing thing, or it could call kernel_thread() or
> anything.  I doubt if any core_initcall functions _do_ do that, but there
> are a lot of them.
> 
> > If not, can we create another initcall level that is guaranteed to run
> > before any threads are spawned?
> 
> It's a simple and cheap matter to create a precore_initcall() - one would
> need to document it carefully to be able to preserve whatever guarantees it
> needs.
> 
> However by the time the initcalls get run, various thing are already
> happening: SMP is up, the keventd threads are running, the CPU scheduler
> migration threads are running, ksoftirqd, softlockup-detector, etc.
> keventd is the problematic one.
> 
> So I guess you'd need a new linker section and a call from
> do_pre_smp_initcalls() or thereabouts.

Hmmm...  OK then, for the moment, I will stick with the current checks
in the primitives.  Not that I particularly like the "bulking up" of
srcu_read_lock() and srcu_read_unlock() -- but if the super-fast
version is needed, it can easily be provided either within the
confines of the subsystem that needs it, or as yet another set of
RCU-like primitives.  Hopefully this latter option can be avoided!

BTW, the reason for the hardluckref is that I don't want to inflict a
failure return from srcu_read_lock() on you guys.  The non-blocking
synchronization community has repeatedly made that sort of mistake,
and I have no intention of letting it propagate any further.  ;-)

						Thanx, Paul
-
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/