All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: Fix vmtruncate() regression
Date: Wed, 13 Jan 2010 17:07:34 +1100	[thread overview]
Message-ID: <20100113060734.GC3901@nick> (raw)
In-Reply-To: <876378jxhx.fsf@devron.myhome.or.jp>

On Tue, Jan 12, 2010 at 03:40:42AM +0900, OGAWA Hirofumi wrote:
> Hi,
> 
> Could you review this one?
> 
> 
> 
> If __block_prepare_write() was failed in block_write_begin(), the
> allocated blocks can be outside of ->i_size.
> 
> But new truncate_pagecache() in vmtuncate() does nothing if new < old.
> It means the above usage is not working anymore.
> 
> So, this patch fixes it by removing "new < old" check. It would need
> more cleanup/change. But, now -rc and truncate working is in progress,
> so, this tried to fix it minimum change.
> 
> Cc: stable@kernel.org
> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Hmm, truncate_pagecache() is for truncating the mm/vm part of the
pagecache. vmtruncate should still call inode->i_op->truncate() to
trim blocks if required.

However I'd say we do still need to ensure do_invalidatepage is
called for the page, for private metadata. So yes I think your patch
looks good.

Acked-by: Nick Piggin <npiggin@suse.de>

Please apply to mainline and 2.6.32.

> ---
> 
>  mm/truncate.c |   28 +++++++++++++---------------
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> diff -puN mm/truncate.c~truncate_pagecache-fix mm/truncate.c
> --- linux-2.6/mm/truncate.c~truncate_pagecache-fix	2010-01-12 02:41:27.000000000 +0900
> +++ linux-2.6-hirofumi/mm/truncate.c	2010-01-12 02:42:53.000000000 +0900
> @@ -522,22 +522,20 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages
>   */
>  void truncate_pagecache(struct inode *inode, loff_t old, loff_t new)
>  {
> -	if (new < old) {
> -		struct address_space *mapping = inode->i_mapping;
> +	struct address_space *mapping = inode->i_mapping;
>  
> -		/*
> -		 * unmap_mapping_range is called twice, first simply for
> -		 * efficiency so that truncate_inode_pages does fewer
> -		 * single-page unmaps.  However after this first call, and
> -		 * before truncate_inode_pages finishes, it is possible for
> -		 * private pages to be COWed, which remain after
> -		 * truncate_inode_pages finishes, hence the second
> -		 * unmap_mapping_range call must be made for correctness.
> -		 */
> -		unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> -		truncate_inode_pages(mapping, new);
> -		unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> -	}
> +	/*
> +	 * unmap_mapping_range is called twice, first simply for
> +	 * efficiency so that truncate_inode_pages does fewer
> +	 * single-page unmaps.  However after this first call, and
> +	 * before truncate_inode_pages finishes, it is possible for
> +	 * private pages to be COWed, which remain after
> +	 * truncate_inode_pages finishes, hence the second
> +	 * unmap_mapping_range call must be made for correctness.
> +	 */
> +	unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
> +	truncate_inode_pages(mapping, new);
> +	unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1);
>  }
>  EXPORT_SYMBOL(truncate_pagecache);
>  
> _
> 
> -- 
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2010-01-13  6:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-11 18:40 [PATCH] vfs: Fix vmtruncate() regression OGAWA Hirofumi
2010-01-13  6:07 ` Nick Piggin [this message]
2010-01-13 12:07   ` OGAWA Hirofumi
2010-01-13 12:14     ` OGAWA Hirofumi
2010-01-14 22:30       ` Andrew Morton
2010-01-15  0:26         ` OGAWA Hirofumi
2010-01-18  3:51           ` Nick Piggin
2010-01-19 23:52             ` [stable] " Greg KH

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=20100113060734.GC3901@nick \
    --to=npiggin@suse.de \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.