From: Jason Lunz <lunz@falooley.org>
To: David Woodhouse <dwmw2@infradead.org>, Nick Piggin <npiggin@suse.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
jffs-dev@axis.com, Hugh Dickins <hugh@veritas.com>
Subject: [jffs2] [rfc] fix write deadlock regression
Date: Sat, 1 Sep 2007 12:06:03 -0700 [thread overview]
Message-ID: <20070901190602.GA5926@falooley.org> (raw)
In-Reply-To: <20070831212636.GB12868@falooley.org>
I've bisected the deadlock when many small appends are done on jffs2 down to
this commit:
commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2
Author: Nick Piggin <npiggin@suse.de>
Date: Sun May 6 14:49:04 2007 -0700
mm: make read_cache_page synchronous
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate calls.
I didn't have a great look down the call chains, but this appears to fixes 7
possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
block2mtd. All depending on whether the filler is async and/or can return
with a !uptodate page.
It introduced a wait to read_cache_page, as well as a
read_cache_page_async function equivalent to the old read_cache_page
without any callers.
Switching jffs2_gc_fetch_page to read_cache_page_async for the old
behavior makes the deadlocks go away, but maybe reintroduces the
use-before-uptodate problem? I don't understand the mm/fs interaction
well enough to say.
Someone more knowledgable should see if similar deadlock issues may have
been introduced for other read_cache_page callers, including the other
two in jffs2.
Signed-off-by: Jason Lunz <lunz@falooley.org>
---
fs/jffs2/fs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 1d3b7a9..8bc727b 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -627,7 +627,7 @@ unsigned char *jffs2_gc_fetch_page(struct jffs2_sb_info *c,
struct inode *inode = OFNI_EDONI_2SFFJ(f);
struct page *pg;
- pg = read_cache_page(inode->i_mapping, offset >> PAGE_CACHE_SHIFT,
+ pg = read_cache_page_async(inode->i_mapping, offset >> PAGE_CACHE_SHIFT,
(void *)jffs2_do_readpage_unlock, inode);
if (IS_ERR(pg))
return (void *)pg;
next prev parent reply other threads:[~2007-09-01 19:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 18:23 jffs2 deadlock introduced in linux 2.6.22.5 Jason Lunz
2007-08-31 21:26 ` Jason Lunz
2007-08-31 21:32 ` Jesper Juhl
2007-09-01 19:06 ` Jason Lunz [this message]
2007-09-02 4:20 ` [jffs2] [rfc] fix write deadlock regression Nick Piggin
2007-09-02 12:13 ` David Woodhouse
2007-09-02 13:20 ` Nick Piggin
2007-09-02 13:48 ` David Woodhouse
2007-09-02 14:17 ` Nick Piggin
2007-09-02 16:15 ` David Woodhouse
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=20070901190602.GA5926@falooley.org \
--to=lunz@falooley.org \
--cc=dwmw2@infradead.org \
--cc=hugh@veritas.com \
--cc=jffs-dev@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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