All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miao Xie <miaox@cn.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: paulmck@linux.vnet.ibm.com, Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	containers@lists.linux-foundation.org, balbir@linux.vnet.ibm.com,
	lizf@cn.fujitsu.com, Oleg Nesterov <oleg@redhat.com>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: Lockdep splat in cpuset code acquiring alloc_lock
Date: Thu, 15 Apr 2010 14:39:47 +0800	[thread overview]
Message-ID: <4BC6B4B3.8070000@cn.fujitsu.com> (raw)
In-Reply-To: <z2m6599ad831004141410tdc40feb0h529dabe4a39d67d5@mail.gmail.com>

CC Oleg
CC Ingo

on 2010-4-15 5:10, Paul Menage wrote:
> Looks like select_fallback_rq() shouldn't be calling
> cpuset_cpus_allowed_locked(), which does a task_lock(), which isn't
> IRQ safe. Also, according to its comments that should only be held
> with the cpuset callback_mutex held, which seems unlikely from a
> softirq handler.
> 
> Also, calling cpuset_cpus_allowed_locked(p, &p->cpus_allowed) stomps
> on state in p without (AFAICS) synchronization.
> 
> The description of commit e76bd8d9850c2296a7e8e24c9dce9b5e6b55fe2f
> includes the phrase " I'm fairly sure this works, but there might be a
> deadlock hiding" although I think that the lockdep-reported problem is
> different than what Rusty had in mind.

This problem have been fixed by Oleg Nesterov, and the patchset was merged
into tip tree, but it's scheduled for .35 ...

http://lkml.org/lkml/2010/3/15/73

Thanks!
Miao


WARNING: multiple messages have this Message-ID (diff)
From: Miao Xie <miaox@cn.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: paulmck@linux.vnet.ibm.com, Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	containers@lists.linux-foundation.org, balbir@linux.vnet.ibm.com,
	lizf@cn.fujitsu.com, Oleg Nesterov <oleg@redhat.com>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: Lockdep splat in cpuset code acquiring alloc_lock
Date: Thu, 15 Apr 2010 14:39:47 +0800	[thread overview]
Message-ID: <4BC6B4B3.8070000@cn.fujitsu.com> (raw)
In-Reply-To: <z2m6599ad831004141410tdc40feb0h529dabe4a39d67d5@mail.gmail.com>

CC Oleg
CC Ingo

on 2010-4-15 5:10, Paul Menage wrote:
> Looks like select_fallback_rq() shouldn't be calling
> cpuset_cpus_allowed_locked(), which does a task_lock(), which isn't
> IRQ safe. Also, according to its comments that should only be held
> with the cpuset callback_mutex held, which seems unlikely from a
> softirq handler.
> 
> Also, calling cpuset_cpus_allowed_locked(p, &p->cpus_allowed) stomps
> on state in p without (AFAICS) synchronization.
> 
> The description of commit e76bd8d9850c2296a7e8e24c9dce9b5e6b55fe2f
> includes the phrase " I'm fairly sure this works, but there might be a
> deadlock hiding" although I think that the lockdep-reported problem is
> different than what Rusty had in mind.

This problem have been fixed by Oleg Nesterov, and the patchset was merged
into tip tree, but it's scheduled for .35 ...

http://lkml.org/lkml/2010/3/15/73

Thanks!
Miao

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2010-04-15  6:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14 20:23 Lockdep splat in cpuset code acquiring alloc_lock Paul E. McKenney
2010-04-14 20:23 ` Paul E. McKenney
     [not found] ` <20100414202347.GA26791-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2010-04-14 21:10   ` Paul Menage
2010-04-14 21:10 ` Paul Menage
2010-04-14 21:10   ` Paul Menage
     [not found]   ` <z2m6599ad831004141410tdc40feb0h529dabe4a39d67d5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-04-15  6:39     ` Miao Xie
2010-04-15  6:39   ` Miao Xie [this message]
2010-04-15  6:39     ` Miao Xie
2010-04-14 20:23 Paul E. McKenney

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=4BC6B4B3.8070000@cn.fujitsu.com \
    --to=miaox@cn.fujitsu.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --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.