All of lore.kernel.org
 help / color / mirror / Atom feed
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 11:00:59 +0800	[thread overview]
Message-ID: <4BAAD1EB.4020201@cn.fujitsu.com> (raw)
In-Reply-To: <20100315091003.GA9123@redhat.com>

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.

Thanks!
Miao


  reply	other threads:[~2010-03-25  3:00 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 [this message]
2010-03-25 10:14   ` Oleg Nesterov
2010-03-25 12:27     ` Miao Xie
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=4BAAD1EB.4020201@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.