lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 2 Sep 2007 06:20:12 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Jason Lunz <lunz@...ooley.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>, jffs-dev@...s.com,
	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [jffs2] [rfc] fix write deadlock regression

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

Powered by blists - more mailing lists