From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, jens.axboe@oracle.com,
linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [mmotm][BUG] lockdep warning block I/O (Was Re: mmotm 2009-08-27-16-51 uploaded
Date: Thu, 3 Sep 2009 14:28:36 -0700 [thread overview]
Message-ID: <20090903142836.fef35b23.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090901180717.f707c58f.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, 1 Sep 2009 18:07:17 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> Here is mmont-Aug27's lockdep wanring. This was printed out when oom-kill happens.
> I'm sorry if already fixed.
My life's project is to hunt down the guy who invented mail client
wordwrapping, set him on fire then dance on his ashes.
> =
> Sep 1 18:01:16 localhost kernel: [ 3012.503035] ======================================================
> Sep 1 18:01:16 localhost kernel: [ 3012.503039] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
> Sep 1 18:01:16 localhost kernel: [ 3012.503042] 2.6.31-rc7-mm1 #3
> Sep 1 18:01:16 localhost kernel: [ 3012.503049] ------------------------------------------------------
> Sep 1 18:01:16 localhost kernel: [ 3012.503052] kblockd/7/350 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> Sep 1 18:01:16 localhost kernel: [ 3012.503058] (bdev_lock){+.+...}, at: [<ffffffff811458c7>] nr_blockdev_pages+0x1
> 7/0x80
> Sep 1 18:01:16 localhost kernel: [ 3012.503069]
> Sep 1 18:01:16 localhost kernel: [ 3012.503070] and this task is already holding:
> Sep 1 18:01:16 localhost kernel: [ 3012.503075] (&q->__queue_lock){..-.-.}, at: [<ffffffff811e9ff8>] cfq_kick_queue
> +0x28/0x50
> Sep 1 18:01:16 localhost kernel: [ 3012.503083] which would create a new lock dependency:
> Sep 1 18:01:16 localhost kernel: [ 3012.503087] (&q->__queue_lock){..-.-.} -> (bdev_lock){+.+...}
> Sep 1 18:01:16 localhost kernel: [ 3012.503100]
I'd say the core problem here is that __alloc_pages_slowpath() is
calling show_mem(). Because show_mem() is a "high level" function which
takes "high level" locks. ie: bdev_lock.
It's inappropriate that alloc_pages() is assuming that it is safe to
call show_mem() from all contexts in which alloc_pages() might be
called.
That show_mem() call has been there since 2005, so I don't know what
caused this to be revealed now.
It's not at all a serious bug and the chances of us deadlocking the
kernel here are close to zero. An appropriate fix would be to replace
that show_mem() call with something which can be safely called from all
contexts in which the page allocator can be called.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, jens.axboe@oracle.com,
linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [mmotm][BUG] lockdep warning block I/O (Was Re: mmotm 2009-08-27-16-51 uploaded
Date: Thu, 3 Sep 2009 14:28:36 -0700 [thread overview]
Message-ID: <20090903142836.fef35b23.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090901180717.f707c58f.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, 1 Sep 2009 18:07:17 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> Here is mmont-Aug27's lockdep wanring. This was printed out when oom-kill happens.
> I'm sorry if already fixed.
My life's project is to hunt down the guy who invented mail client
wordwrapping, set him on fire then dance on his ashes.
> =
> Sep 1 18:01:16 localhost kernel: [ 3012.503035] ======================================================
> Sep 1 18:01:16 localhost kernel: [ 3012.503039] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
> Sep 1 18:01:16 localhost kernel: [ 3012.503042] 2.6.31-rc7-mm1 #3
> Sep 1 18:01:16 localhost kernel: [ 3012.503049] ------------------------------------------------------
> Sep 1 18:01:16 localhost kernel: [ 3012.503052] kblockd/7/350 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> Sep 1 18:01:16 localhost kernel: [ 3012.503058] (bdev_lock){+.+...}, at: [<ffffffff811458c7>] nr_blockdev_pages+0x1
> 7/0x80
> Sep 1 18:01:16 localhost kernel: [ 3012.503069]
> Sep 1 18:01:16 localhost kernel: [ 3012.503070] and this task is already holding:
> Sep 1 18:01:16 localhost kernel: [ 3012.503075] (&q->__queue_lock){..-.-.}, at: [<ffffffff811e9ff8>] cfq_kick_queue
> +0x28/0x50
> Sep 1 18:01:16 localhost kernel: [ 3012.503083] which would create a new lock dependency:
> Sep 1 18:01:16 localhost kernel: [ 3012.503087] (&q->__queue_lock){..-.-.} -> (bdev_lock){+.+...}
> Sep 1 18:01:16 localhost kernel: [ 3012.503100]
I'd say the core problem here is that __alloc_pages_slowpath() is
calling show_mem(). Because show_mem() is a "high level" function which
takes "high level" locks. ie: bdev_lock.
It's inappropriate that alloc_pages() is assuming that it is safe to
call show_mem() from all contexts in which alloc_pages() might be
called.
That show_mem() call has been there since 2005, so I don't know what
caused this to be revealed now.
It's not at all a serious bug and the chances of us deadlocking the
kernel here are close to zero. An appropriate fix would be to replace
that show_mem() call with something which can be safely called from all
contexts in which the page allocator can be called.
--
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>
next prev parent reply other threads:[~2009-09-03 21:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 23:55 mmotm 2009-08-27-16-51 uploaded akpm
2009-09-01 9:00 ` [mmotm][BUG] free is bigger than presnet " KAMEZAWA Hiroyuki
2009-09-01 9:00 ` KAMEZAWA Hiroyuki
2009-09-01 9:33 ` Hugh Dickins
2009-09-01 9:33 ` Hugh Dickins
2009-09-01 9:50 ` KAMEZAWA Hiroyuki
2009-09-01 9:50 ` KAMEZAWA Hiroyuki
2009-09-01 10:10 ` KAMEZAWA Hiroyuki
2009-09-01 10:10 ` KAMEZAWA Hiroyuki
2009-09-01 11:00 ` Hugh Dickins
2009-09-01 11:00 ` Hugh Dickins
2009-09-01 11:23 ` Hugh Dickins
2009-09-01 11:23 ` Hugh Dickins
2009-09-01 11:46 ` KAMEZAWA Hiroyuki
2009-09-01 11:46 ` KAMEZAWA Hiroyuki
2009-09-02 0:08 ` KAMEZAWA Hiroyuki
2009-09-02 0:08 ` KAMEZAWA Hiroyuki
2009-09-01 9:39 ` Johannes Weiner
2009-09-01 9:39 ` Johannes Weiner
2009-09-01 9:07 ` [mmotm][BUG] lockdep warning block I/O (Was " KAMEZAWA Hiroyuki
2009-09-03 21:28 ` Andrew Morton [this message]
2009-09-03 21:28 ` Andrew Morton
2009-09-04 4:21 ` KAMEZAWA Hiroyuki
2009-09-04 4:21 ` KAMEZAWA Hiroyuki
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=20090903142836.fef35b23.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/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.