linux-kernel - Re: [patch 2/5] mm: fault vs invalidate/truncate race fix

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:	Thu, 12 Oct 2006 05:33:58 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Andrew Morton <akpm@...l.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Linux Memory Management <linux-mm@...ck.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2/5] mm: fault vs invalidate/truncate race fix

On Wed, Oct 11, 2006 at 10:38:31AM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 11 Oct 2006, Nick Piggin wrote:
> > 
> > I mean filemap_nopage does *two* synchronous reads when finding a !uptodate
> > page. This is despite the comment saying that it retries once on error.
> 
> Ahh. 
> 
> Yes, now that you point to the actual code, that does look ugly.
> 
> I think it's related to the
> 
> 	ClearPageError(page);
> 
> thing, and probably related to that function being rather old and having 
> gone through several re-organizations. I suspect we used to fall through 
> to the error handling code regardless of whether we did the read ourselves 
> etc.

Yeah, it may have even been a mismerge at some point in time.

> Are you saying that something like this would be preferable?

I think so, it is neater and clearer. I actually didn't even bother relocking
and checking the page again on readpage error so got rid of quite a bit of
code.

> 
> 		Linus
> 
> ---
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 3464b68..e5ecf42 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1496,6 +1496,8 @@ page_not_uptodate:
>  		goto success;
>  	}
>  
> +	/* Clear any potential old errors, and try to read.. */
> +	ClearPageError(page);
>  	error = mapping->a_ops->readpage(file, page);
>  	if (!error) {
>  		wait_on_page_locked(page);
> @@ -1526,21 +1528,12 @@ page_not_uptodate:
>  		unlock_page(page);
>  		goto success;
>  	}
> -	ClearPageError(page);
> -	error = mapping->a_ops->readpage(file, page);
> -	if (!error) {
> -		wait_on_page_locked(page);
> -		if (PageUptodate(page))
> -			goto success;
> -	} else if (error == AOP_TRUNCATED_PAGE) {
> -		page_cache_release(page);
> -		goto retry_find;
> -	}
>  
>  	/*
>  	 * Things didn't work out. Return zero to tell the
>  	 * mm layer so, possibly freeing the page cache page first.
>  	 */
> +	unlock_page(page);
>  	shrink_readahead_size_eio(file, ra);
>  	page_cache_release(page);
>  	return NOPAGE_SIGBUS;
-
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/