From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "alpha @ steudten Engineering" <alpha@steudten.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: INFO: possible circular locking dependency detected
Date: Tue, 17 Oct 2006 00:32:44 +1000 [thread overview]
Message-ID: <4533980C.10403@yahoo.com.au> (raw)
In-Reply-To: <453391A4.5090100@steudten.org>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
alpha @ steudten Engineering wrote:
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.18-1.2189self #1
> -------------------------------------------------------
> kswapd0/186 is trying to acquire lock:
> (&inode->i_mutex){--..}, at: [<c0326e32>] mutex_lock+0x21/0x24
>
> but task is already holding lock:
> (iprune_mutex){--..}, at: [<c0326e32>] mutex_lock+0x21/0x24
>
> which lock already depends on the new lock.
Thanks. __grab_cache_page wants to clear __GFP_FS, because it is
holding the i_mutex so we don't want to reenter the filesystem in
page reclaim.
This would be an easy two liner, except those funny page_cache_alloc
routines which take a mapping rather than a gfp_t argument :P
Anyway, I'll get around to writing the real patch and queue it up
with my other buffered write deadlock fixes. It should be fairly
unlikely to cause you a deadlock. You could give this quick patch a
try, though. Does it fix your problem?
--
SUSE Labs, Novell Inc.
[-- Attachment #2: mm-write-deadlock.patch --]
[-- Type: text/plain, Size: 1442 bytes --]
Index: linux-2.6/include/linux/pagemap.h
===================================================================
--- linux-2.6.orig/include/linux/pagemap.h 2006-10-17 00:29:40.000000000 +1000
+++ linux-2.6/include/linux/pagemap.h 2006-10-17 00:29:50.000000000 +1000
@@ -57,7 +57,7 @@ extern struct page *page_cache_alloc_col
#else
static inline struct page *page_cache_alloc(struct address_space *x)
{
- return alloc_pages(mapping_gfp_mask(x), 0);
+ return alloc_pages(mapping_gfp_mask(x)&~__GFP_FS, 0);
}
static inline struct page *page_cache_alloc_cold(struct address_space *x)
Index: linux-2.6/mm/filemap.c
===================================================================
--- linux-2.6.orig/mm/filemap.c 2006-10-17 00:29:49.000000000 +1000
+++ linux-2.6/mm/filemap.c 2006-10-17 00:29:50.000000000 +1000
@@ -471,9 +471,9 @@ struct page *page_cache_alloc(struct add
{
if (cpuset_do_page_mem_spread()) {
int n = cpuset_mem_spread_node();
- return alloc_pages_node(n, mapping_gfp_mask(x), 0);
+ return alloc_pages_node(n, mapping_gfp_mask(x)&~__GFP_FS, 0);
}
- return alloc_pages(mapping_gfp_mask(x), 0);
+ return alloc_pages(mapping_gfp_mask(x)&~__GFP_FS, 0);
}
EXPORT_SYMBOL(page_cache_alloc);
@@ -1864,7 +1864,7 @@ repeat:
return NULL;
}
err = add_to_page_cache(*cached_page, mapping,
- index, GFP_KERNEL);
+ index, GFP_KERNEL&~__GFP_FS);
if (err == -EEXIST)
goto repeat;
if (err == 0) {
next prev parent reply other threads:[~2006-10-16 14:32 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-16 14:05 INFO: possible circular locking dependency detected alpha @ steudten Engineering
2006-10-16 14:32 ` Nick Piggin [this message]
2006-10-16 15:42 ` Randy Dunlap
2006-10-16 15:46 ` Nick Piggin
2006-10-19 6:02 ` Andrew Morton
2006-10-19 6:30 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2007-02-08 15:03 Pedro M. López
2009-10-10 23:09 John Kacur
2009-12-06 10:11 Richard Zidlicky
2011-07-14 14:49 Sergey Senozhatsky
2011-07-14 16:41 ` Peter Zijlstra
2011-07-14 16:57 ` Paul E. McKenney
2011-07-14 19:16 ` Sergey Senozhatsky
2011-07-14 19:15 ` Sergey Senozhatsky
2011-07-14 19:34 ` Paul E. McKenney
2011-07-14 19:38 ` Dave Jones
2011-07-14 20:33 ` Paul E. McKenney
2011-07-14 19:38 ` Sergey Senozhatsky
2011-07-14 16:58 ` Steven Rostedt
2011-07-14 17:02 ` Steven Rostedt
2011-07-14 17:05 ` Paul E. McKenney
2011-07-14 17:32 ` Steven Rostedt
2011-07-14 17:46 ` Steven Rostedt
2011-07-14 19:18 ` Paul E. McKenney
2011-07-14 19:41 ` Steven Rostedt
2011-07-14 20:33 ` Paul E. McKenney
2011-07-15 11:05 ` Ed Tomlinson
2011-07-15 11:29 ` Peter Zijlstra
2011-07-15 11:35 ` Ed Tomlinson
2011-07-15 11:39 ` Peter Zijlstra
2011-07-15 18:11 ` Paul E. McKenney
2011-07-15 12:42 ` Paul E. McKenney
2011-07-15 13:07 ` Peter Zijlstra
2011-07-15 14:36 ` Paul E. McKenney
2011-07-15 15:04 ` Peter Zijlstra
2011-07-15 15:59 ` Paul E. McKenney
2011-07-15 16:11 ` Peter Zijlstra
2011-07-15 16:56 ` Paul E. McKenney
2011-07-15 21:48 ` Ed Tomlinson
2011-07-15 22:04 ` Paul E. McKenney
2011-07-16 19:42 ` Ed Tomlinson
2011-07-17 0:02 ` Paul E. McKenney
2011-07-17 1:56 ` Ed Tomlinson
2011-07-17 14:28 ` Paul E. McKenney
2011-07-18 15:15 ` Paul E. McKenney
2011-07-18 9:29 ` Peter Zijlstra
2011-07-18 15:29 ` Paul E. McKenney
2011-07-15 16:55 ` Steven Rostedt
2011-07-15 17:03 ` Paul E. McKenney
2011-07-15 17:16 ` Steven Rostedt
2011-07-15 17:24 ` Paul E. McKenney
2011-07-15 17:42 ` Steven Rostedt
2011-07-15 18:33 ` Paul E. McKenney
2011-08-07 16:22 Justin P. Mattock
2011-08-11 20:57 ` Justin P. Mattock
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=4533980C.10403@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=alpha@steudten.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox