On Sat, Sep 01, 2007 at 12:06:03PM -0700, Jason Lunz wrote: > > 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.
Hmm, thanks for that. It does sound like it is deadlocking via commit_write(). OTOH, it seems like it could be using the page before it is uptodate -- it _may_ only be dealing with uptodate data at that point... but if so, why even read_cache_page at all? However, it is a regression. So unless David can come up with a more satisfactory approach, I guess we'd have to go with your patch. > > Signed-off-by: Jason Lunz <[EMAIL PROTECTED]> > > --- > 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; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
