From: Miao Xie <miaox@cn.fujitsu.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>, Ben Blum <bblum@google.com>,
Jiri Slaby <jirislaby@gmail.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Li Zefan <lizf@cn.fujitsu.com>, Paul Menage <menage@google.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code
Date: Thu, 25 Mar 2010 20:27:10 +0800 [thread overview]
Message-ID: <4BAB569E.5060103@cn.fujitsu.com> (raw)
In-Reply-To: <20100325101420.GA30779@redhat.com>
on 2010-3-25 18:14, Oleg Nesterov wrote:
> On 03/25, Miao Xie wrote:
>>
>> on 2010-3-15 17:10, Oleg Nesterov wrote:
>>> This patch just states the fact the cpusets/cpuhotplug interaction is
>>> broken and removes the deadlockable code which only pretends to work.
>>>
>>> - cpuset_lock() doesn't really work. It is needed for
>>> cpuset_cpus_allowed_locked() but we can't take this lock in
>>> try_to_wake_up()->select_fallback_rq() path.
>>>
>>> - cpuset_lock() is deadlockable. Suppose that a task T bound to CPU takes
>>> callback_mutex. If cpu_down(CPU) happens before T drops callback_mutex
>>> stop_machine() preempts T, then migration_call(CPU_DEAD) tries to take
>>> cpuset_lock() and hangs forever because CPU is already dead and thus
>>> T can't be scheduled.
>>
>> The problem what you said don't exist, because the kernel already move T to
>> the active cpu when preparing to turn off a CPU.
>
> we need cpuset_lock() to move T. please look at _cpu_down().
>
> OK.
>
> A task T holds callback_mutex, and it is bound to CPU 1.
>
> _cpu_down(cpu => 1) is called by the task X.
>
> _cpu_down()->stop_machine() spawns rt-threads for each cpu,
> a thread running on CPU 1 preempts T and calls take_cpu_down()
> which removes CPU 1 from online/active masks.
>
> X continues, and does raw_notifier_call_chain(CPU_DEAD), this
> calls migration_call(CPU_DEAD), and _this_ is what move the
> tasks from the dead CPU.
>
> migration_call(CPU_DEAD) calls cpuset_lock() and deadlocks.
>
> See?
But when the kernel want to offline a cpu, it does
raw_notifier_call_chain(CPU_DOWN_PREPARE)
at first. this calls cpuset_track_online_cpus() to update cpuset's cpus
and task->cpus_allowed, and then moves the task running on the dying cpu
to the other online cpu. At that time, rt-threads for each cpu have not
been created.
And when the kernel does migration_call(CPU_DEAD), the rt-threads already
exit. the task that holds callback_mutex can run as normal.
Miao
>
> Oleg.
>
>
>
>
next prev parent reply other threads:[~2010-03-25 12:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-15 9:10 [PATCH 1/6] kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code Oleg Nesterov
2010-03-25 3:00 ` Miao Xie
2010-03-25 10:14 ` Oleg Nesterov
2010-03-25 12:27 ` Miao Xie [this message]
2010-03-25 12:59 ` Oleg Nesterov
2010-04-02 19:11 ` [tip:sched/core] sched: Kill " tip-bot for Oleg Nesterov
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=4BAB569E.5060103@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=bblum@google.com \
--cc=jirislaby@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@sisk.pl \
--cc=tj@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.