public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Olaf Hering <olh@suse.de>
Cc: linux-kernel@vger.kernel.org, viro@ftp.linux.org.uk
Subject: Re: [PATCH] cramfs corruption after BLKFLSBUF on loop device
Date: Fri, 2 Jun 2006 12:41:43 -0700	[thread overview]
Message-ID: <20060602124143.0898384f.akpm@osdl.org> (raw)
In-Reply-To: <20060602191430.GA9357@suse.de>

On Fri, 2 Jun 2006 21:14:30 +0200
Olaf Hering <olh@suse.de> wrote:

>  On Fri, Jun 02, Andrew Morton wrote:
> 
> > I'd suggest you run SetPagePrivate() and SetPageChecked() on the locked
> > page and implement a_ops.releasepage(), which will fail if PageChecked(),
> > and will succeed otherwise:
> > 
> > /*
> >  * cramfs_releasepage() will fail if cramfs_read() set PG_checked.  This
> >  * is so that invalidate_inode_pages() cannot zap the page while
> >  * cramfs_read() is trying to get at its contents.
> >  */
> > cramfs_releasepage(...)
> > {
> > 	if (PageChecked(page))
> > 		return 0;
> > 	return 1;
> > }
> 
> This function is not triggered in my testing.
> 
> > cramfs_read(...)
> > {
> > 	lock_page(page);
> > 	SetPagePrivate(page);
> > 	SetPageChecked(page);
> > 	read_mapping_page(...);
> > 	lock_page(page);
> > 	if (page->mapping == NULL) {
> > 		/* truncate got there first */
> > 		unlock_page(page);
> > 		bale();
> > 	}
> > 	memcpy();
> > 	ClearPageChecked(page);
> > 	ClearPagePrivate(page);
> > 	unlock_page(page);
> > }
> 
> recursive recursion? Where is page supposed to come from? Did you mean
> to call all this with a page returned from read_mapping_page(), and
> call read_mapping_page() twice?

That was all very-pseudo code.

> My version seems to leak memory somehow, Inactive and slab buffer_head
> keeps growing. I guess something is missing in the picture.
> 
> Doesnt read_cache_page lock the page already?
> read_cache_page
>   __read_cache_page
>     add_to_page_cache_lru
>       add_to_page_cache
>         SetPageLocked

read_cache_page() returns with the page locked if there's IO in flight
against it.

>  
> +static void cramfs_read_putpage(struct page *page)
> +{
> +	ClearPageChecked(page);
> +	ClearPagePrivate(page);
> +	unlock_page(page);
> +	page_cache_release(page);
> +}
> +
> +/* return a page in PageUptodate state, BLKFLSBUF may have flushed the page */
> +static struct page *cramfs_read_getpage(struct address_space *m, unsigned int n)
> +{
> +	struct page *page;
> +	int readagain = 5;
> +retry:
> +	page = read_cache_page(m, n, (filler_t *)m->a_ops->readpage, NULL);
> +	if (IS_ERR(page))
> +		return NULL;
> +	lock_page(page);
> +	SetPagePrivate(page);
> +	SetPageChecked(page);
> +	if (PageUptodate(page))
> +		return page;
> +	cramfs_read_putpage(page);
> +	printk("cramfs_read_getpage %d %p\n", 5 - readagain + 1, page);
> +	if (readagain--)
> +		goto retry;
> +	return NULL;
> +}

Oh, OK, we cannot use read_cache_page().  Because the above is still racy
(and still needs the retry loop).  We need to set PG_checked before
launching the read.  Something like:

/*
 * Return a locked, uptodate, !PagePrivate, !PageChecked page which needs a
 * single put_page by the caller.
 */
cramfs_read_getpage()
{
	page = find_lock_page()
	if (PageUptodate(page))
		return page;
	SetPagePrivate()
	SetPageChecked()
	err = m->a_ops->readpage(page);
	if (err) {
		ClearPageChecked(page);
		ClearPagePrivate(page);
		put_page(page);
		return NULL;
	}
	lock_page(page);
	ClearPageChecked(page);
	ClearPagePrivate(page);
	if (page->mapping == NULL) {
		/* truncate got there first */
		unlock_page(page);
		put_page(page);
		return NULL;
	}
	if (PageError(page)) {
		/* IO error */
		unlock_page(page);
		put_page(page);
		return NULL;
	}
	return page;			/* It's locked */
	

You'll see that the timing window here for invalidate_inode_pages() is very
small - invalidate has to come in at the exact right time after the page has
come unlocked so that its trylock wins the race against this function.

So I'd suggest that to get the cramfs_releasepage() code path tested you'd
need to do:

	wait_on_page_locked();
	msleep(1);
	lock_page()

above, to give invalidate a wider window to hit.

> +		if (blocknr + i < devsize) {
> +			page = cramfs_read_getpage(mapping, blocknr + i);
> +			if (page) {
> +				memcpy(data, kmap_atomic(page, KM_USER0), PAGE_CACHE_SIZE);
> +				kunmap_atomic(page, KM_USER0);

kunmap_atomic() takes the virtual address, not a page*

	void *kaddr = kmap_atomic(...);
	memcpy(..., kaddr, ...);
	kunmap_atomic(kaddr);

As to why it's leaking: dunno, sorry.  It looks OK.

  reply	other threads:[~2006-06-02 19:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 21:40 cramfs corruption after BLKFLSBUF on loop device Olaf Hering
2006-05-30 13:19 ` Olaf Hering
2006-05-30 18:24 ` Olaf Hering
2006-06-01 18:49   ` [PATCH] " Olaf Hering
2006-06-01 19:12     ` Andrew Morton
2006-06-01 19:15       ` Andrew Morton
2006-06-01 20:10       ` Olaf Hering
2006-06-01 21:24         ` Andrew Morton
2006-06-01 21:41           ` Olaf Hering
2006-06-01 21:57             ` Andrew Morton
2006-06-02  8:43               ` Olaf Hering
2006-06-02  9:11                 ` Andrew Morton
2006-06-02 19:14                   ` Olaf Hering
2006-06-02 19:41                     ` Andrew Morton [this message]
2006-06-02 21:06                       ` Olaf Hering
2006-06-02 19:37                   ` Olaf Hering
2006-06-02 19:46                     ` Andrew Morton
2006-06-03 13:13                       ` Olaf Hering
2006-06-01 20:17     ` Chris Mason
2006-06-01 20:20       ` Olaf Hering
2006-06-01 20:29         ` Chris Mason
2006-09-20 13:20     ` Olaf Hering
2006-09-20 18:47       ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060602124143.0898384f.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olh@suse.de \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox