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-next>] [day] [month] [year] [list]
Date:	Fri, 20 Apr 2012 13:05:41 -0000
From:	Thomas Gleixner <tglx@...utronix.de>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	linux-arch@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...nel.org>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1

Dear all,

I'm working on refactoring the SMP boot and CPU hotplug implementation.

The current code has evolved over time into a conglomerate of
warts. My main goals are to:

 - reduce the architecture code by moving repeating constructs to the
   core

 - redesigning the handling of per cpu threads. There is no point to
   tear down the threads just to create them again.

 - restructuring the notifier facility into a proper tree with
   dependencies to avoid the gazillion of callbacks and moving
   setup/teardown code into the context of the upcoming/dying cpu

The motivation behind this work is the cpu hotplug nightmare which we
are facing in the RT kernel and the requests from several groups
(e.g. ARM) to make hotplug more lightweight and faster.

This first part moves the idle thread management for non-boot cpus
into the core. fork_idle() is called in a workqueue as it is
implemented in a few architectures already. This is necessary when not
all cpus are brought up by the early boot code as otherwise we would
take a ref on the user task VM of the thread which brings the cpu up
via the sysfs interface.

This converts all architectures except m32r, mn10300, tile and UM to
the new core facility. These architecture are calling fork_idle() in
the very early boot code in smp_prepare_cpus() for unknown reasons.
I haven't analyzed yet, whether this is on purpose or can be moved
over to the generic facility. It'd be nice if the responsible maintainers
could look into that as well.

Thanks,

	tglx



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ