All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Robin Holt <holt@sgi.com>
Cc: Ingo Molnar <mingo@redhat.com>, Russ Anderson <rja@sgi.com>,
	Shawn Guo <shawn.guo@linaro.org>, Oleg Nesterov <oleg@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Joe Perches <joe@perches.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Michel Lespinasse <walken@google.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
	Tejun Heo <tj@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Patch -v4 1/4] Migrate shutdown/reboot to boot cpu.
Date: Wed, 17 Apr 2013 09:46:53 +0200	[thread overview]
Message-ID: <20130417074653.GA31607@gmail.com> (raw)
In-Reply-To: <20130416140101.GS3658@sgi.com>


* Robin Holt <holt@sgi.com> wrote:

> > 		reboot_cpu_id = cpumask_first(cpu_online_mask);
> > 
> > > Also, does this codepath prevent hotplug from going on in parallel?
> > 
> > Not sure.  I have not considered hotplug.  I will look that over when I
> > am in the office.
> 
> OK.  I have been mulling this over for a bit and I don't think I
> understand what you are asking.

Well, I just saw the apparently naked use of cpu_online_mask, and asked myself 
whether that's safe against hotplug.

Upstream we had two methods:

 - historical: just reboot on any random CPU we happen to run on
 - current: offline all nonboot CPUs then reboot on the boot CPU

Both methods were implicitly "CPU hotplug safe", no locking needed, because either 
they didn't need any, or because it used disable_nonboot_cpus() which is a hotplug 
safe method.

Now your patches change this to:

 - migrate to CPU#0 [if possible] and reboot there

Given that on a system CPU-hotplugging might be executing on any given CPU, if 
reboot is running on another you have to consider the interactions. The previous 
historic and current upstream method was reasonably hotplug safe - yours I'm not 
sure about, there's just no hotplug locking in it, etc?

> I would expect that if an architecture depends upon a certain cpu for 
> shutdown/reboot/halt/suspend/hibernate and that support has been compiled in, 
> then the arch should be preventing that cpu from being removed. I do not know 
> how that would work and think that is far beyond the scope of the initial 
> problem I have been trying to solve.  If that is your question, I certainly do 
> not know how to address it.  I get the feeling this is off your mark due to the 
> "parallel" wording above.

What you mention here should indeed already be handled by the architecture hotplug 
code (for example on x86 the boot CPU cannot be hot-removed).

But beyond that, your use of cpu_online_map is AFAICS not hotplug-safe. For 
example a possible race would be that another CPU might be not-unplugging a CPU 
and you try to reboot-migrate to it.

Thanks,

	Ingo

  reply	other threads:[~2013-04-17  7:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16  9:58 [Patch -v4 1/4] Migrate shutdown/reboot to boot cpu Robin Holt
2013-04-16 11:32 ` Ingo Molnar
2013-04-16 12:06   ` Robin Holt
2013-04-16 14:01     ` Robin Holt
2013-04-17  7:46       ` Ingo Molnar [this message]
2013-04-17  9:27         ` Borislav Petkov
2013-04-19  7:56           ` Ingo Molnar
2013-04-19  8:29             ` Srivatsa S. Bhat
2013-04-19  8:44               ` Ingo Molnar
2013-04-16 15:48     ` Srivatsa S. Bhat
2013-04-16 16:22       ` Robin Holt
2013-04-17  7:48         ` Ingo Molnar
2013-04-17 10:03           ` Robin Holt
2013-04-17 11:31             ` Srivatsa S. Bhat
2013-04-17 11:58               ` Robin Holt

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=20130417074653.GA31607@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=holt@sgi.com \
    --cc=hpa@zytor.com \
    --cc=joe@perches.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rja@sgi.com \
    --cc=rusty@rustcorp.com.au \
    --cc=shawn.guo@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=walken@google.com \
    --cc=x86@kernel.org \
    /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.