On Sat, Sep 01, 2007 at 12:06:03PM -0700, Jason Lunz wrote:
quoted text
> 
> 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.



quoted text
> 
>     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;
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/