All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akinobu Mita <akinobu.mita@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Dmitriy Zavin <dmitriyz@google.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>, Ashok Raj <ashok.raj@intel.com>,
	Akinobu Mita <akinobu.mita@gmail.com>
Subject: [patch 3/9] cpu: deliver CPU_UP_CANCELED only to NOTIFY_OKed callbacks with CPU_UP_PREPARE
Date: Mon, 23 Jul 2007 00:33:15 +0900	[thread overview]
Message-ID: <20070722153349.369335694@gmail.com> (raw)
In-Reply-To: 20070722153312.083951746@gmail.com

[-- Attachment #1: cpuhotplug-nr-calls.patch --]
[-- Type: text/plain, Size: 2349 bytes --]

From: Akinobu Mita <akinobu.mita@gmail.com>

The functions in a CPU notifier chain is called with CPU_UP_PREPARE event
before making the CPU online. If one of the callback returns NOTIFY_BAD,
it stops to deliver CPU_UP_PREPARE event, and CPU online operation is canceled.
Then CPU_UP_CANCELED event is delivered to the functions in a CPU notifier
chain again.

This CPU_UP_CANCELED event is delivered to the functions which have been
called with CPU_UP_PREPARE, not delivered to the functions which haven't
been called with CPU_UP_PREPARE.

The problem that makes existing cpu hotplug error handlings complex is
that the CPU_UP_CANCELED event is delivered to the function that has
returned NOTIFY_BAD, too.

Usually we don't expect to call destructor function against the
object that has failed to initialize. It is like:

	err = register_something();
	if (err) {
		unregister_something();
		return err;
	}

So it is natural to deliver CPU_UP_CANCELED event only to the functions
that have returned NOTIFY_OK with CPU_UP_PREPARE event and not to call
the function that have returned NOTIFY_BAD. This is what this patch is doing.

Otherwise, every cpu hotplug notifiler has to track whether
notifiler event is failed or not for each cpu.
(drivers/base/topology.c is doing this with topology_dev_map)

Similary this patch makes same thing with CPU_DOWN_PREPARE and
CPU_DOWN_FAILED evnets.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>

---
 kernel/cpu.c |    2 ++
 1 file changed, 2 insertions(+)

Index: 2.6-git/kernel/cpu.c
===================================================================
--- 2.6-git.orig/kernel/cpu.c
+++ 2.6-git/kernel/cpu.c
@@ -150,6 +150,7 @@ static int _cpu_down(unsigned int cpu, i
 	err = __raw_notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE | mod,
 					hcpu, -1, &nr_calls);
 	if (err == NOTIFY_BAD) {
+		nr_calls--;
 		__raw_notifier_call_chain(&cpu_chain, CPU_DOWN_FAILED | mod,
 					  hcpu, nr_calls, NULL);
 		printk("%s: attempt to take down CPU %u failed\n",
@@ -233,6 +234,7 @@ static int __cpuinit _cpu_up(unsigned in
 	ret = __raw_notifier_call_chain(&cpu_chain, CPU_UP_PREPARE | mod, hcpu,
 							-1, &nr_calls);
 	if (ret == NOTIFY_BAD) {
+		nr_calls--;
 		printk("%s: attempt to bring up CPU %u failed\n",
 				__FUNCTION__, cpu);
 		ret = -EINVAL;

-- 

  parent reply	other threads:[~2007-07-22 15:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-22 15:33 [patch 0/9] CPU hotplug error handling fixes take2 Akinobu Mita
2007-07-22 15:33 ` [patch 1/9] slab: cleanup cpuup_callback() Akinobu Mita
2007-07-22 15:33 ` [patch 2/9] slab: fix memory leak in cpu hotplug error path Akinobu Mita
2007-07-24  9:46   ` Pekka Enberg
2007-07-22 15:33 ` Akinobu Mita [this message]
2007-07-22 23:48   ` [patch 3/9] cpu: deliver CPU_UP_CANCELED only to NOTIFY_OKed callbacks with CPU_UP_PREPARE Rusty Russell
2007-07-22 15:33 ` [patch 4/9] topology: remove topology_dev_map Akinobu Mita
2007-07-23 23:16   ` Greg KH
2007-07-22 15:33 ` [patch 5/9] thermal_throttle: fix cpu hotplug error handling Akinobu Mita
2007-07-22 15:33 ` [patch 6/9] msr: " Akinobu Mita
2007-07-22 15:33 ` [patch 7/9] cpuid: " Akinobu Mita
2007-07-22 15:33 ` [patch 8/9] mce: " Akinobu Mita
2007-07-22 15:33 ` [patch 9/9] intel_cacheinfo: " Akinobu Mita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070722153349.369335694@gmail.com \
    --to=akinobu.mita@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=ashok.raj@intel.com \
    --cc=dmitriyz@google.com \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.