From: Shaohua Li <shaohua.li@intel.com>
To: vatsa@in.ibm.com
Cc: Nigel Cunningham <ncunningham@cyclades.com>,
Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: PATCH: Fix race in cpu_down (hotplug cpu)
Date: Mon, 19 Sep 2005 13:31:27 +0800 [thread overview]
Message-ID: <1127107887.3958.9.camel@linux-hp.sh.intel.com> (raw)
In-Reply-To: <20050919051024.GA8653@in.ibm.com>
On Mon, 2005-09-19 at 10:40 +0530, Srivatsa Vaddagiri wrote:
> On Mon, Sep 19, 2005 at 12:48:38PM +0800, Li, Shaohua wrote:
> > I guess Nigel's point is cpu_idle is preempted before take_cpu_down. If
> > the preempt occurs after the cpu_is_offline check, when the cpu (after
>
> How can that happen? Idle task is running at max priority (MAX_RT_PRIO-1)
> and with SCHED_FIFO policy at this point. If that is indeed happening,
> then we need to modify sched_idle_next not to allow that.
A CPU is idle and then is preempted and starting offline CPU. After
calling stop_machine_run, the CPU goes into idle and it will resume last
idle loop. If the CPU is broken at specific point, then the CPU will
continue executing previous idle and have no chance to call play_dead.
Am I missing anything? Nigel's patch seems can fix the situation for
mwait_idle and poll_idle but can't fix for default_idle in i386 to me.
Thanks,
Shaohua
next prev parent reply other threads:[~2005-09-19 5:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 4:48 PATCH: Fix race in cpu_down (hotplug cpu) Li, Shaohua
2005-09-19 5:10 ` Srivatsa Vaddagiri
2005-09-19 5:31 ` Shaohua Li [this message]
2005-09-19 5:57 ` Srivatsa Vaddagiri
2005-09-19 6:11 ` Nigel Cunningham
2005-09-19 6:23 ` Srivatsa Vaddagiri
2005-09-19 6:29 ` Nick Piggin
2005-09-19 7:00 ` Srivatsa Vaddagiri
2005-09-19 6:31 ` Nigel Cunningham
2005-09-19 7:09 ` Srivatsa Vaddagiri
2005-09-19 6:37 ` Shaohua Li
2005-09-19 6:36 ` Nick Piggin
2005-09-19 6:54 ` Nigel Cunningham
2005-09-19 7:12 ` Shaohua Li
2005-09-19 7:22 ` Nick Piggin
2005-09-19 7:28 ` Ingo Molnar
2005-09-19 7:37 ` Nick Piggin
2005-09-19 22:55 ` Nigel Cunningham
2005-09-20 4:41 ` Srivatsa Vaddagiri
2005-09-19 7:07 ` Srivatsa Vaddagiri
2005-09-19 5:23 ` Nigel Cunningham
2005-09-19 5:28 ` Srivatsa Vaddagiri
2005-09-19 5:35 ` Nigel Cunningham
2005-09-19 7:43 ` Where do packets sent to 255.255.255.255 go? Wei-Che, Hsu
-- strict thread matches above, loose matches on Subject: below --
2005-09-19 3:28 PATCH: Fix race in cpu_down (hotplug cpu) Nigel Cunningham
2005-09-19 4:22 ` Srivatsa Vaddagiri
2005-09-19 3:15 Nigel Cunningham
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=1127107887.3958.9.camel@linux-hp.sh.intel.com \
--to=shaohua.li@intel.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ncunningham@cyclades.com \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@osdl.org \
--cc=vatsa@in.ibm.com \
--cc=zwane@arm.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox