diff options
author | Jason Lunz <lunz@falooley.org> | 2007-09-01 21:06:03 +0200 |
---|---|---|
committer | David Woodhouse <dwmw2@infradead.org> | 2007-09-02 19:18:38 +0200 |
commit | fc0e01974ccccc7530b7634a63ee3fcc57b845ea (patch) | |
tree | 2680036a725a5cef83330ea618aa77e0494880ec /fs/xattr_acl.c | |
parent | Linux 2.6.23-rc5 (diff) | |
download | linux-fc0e01974ccccc7530b7634a63ee3fcc57b845ea.tar.xz linux-fc0e01974ccccc7530b7634a63ee3fcc57b845ea.zip |
[JFFS2] fix write deadlock regression
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.
[It's fine. dwmw2.]
Signed-off-by: Jason Lunz <lunz@falooley.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Diffstat (limited to 'fs/xattr_acl.c')
0 files changed, 0 insertions, 0 deletions