All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
@ 2011-09-16  8:59 Li Zefan
  2011-09-16 16:39 ` Sage Weil
  0 siblings, 1 reply; 5+ messages in thread
From: Li Zefan @ 2011-09-16  8:59 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Sage Weil

It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
(Btrfs: truncate pages from clone ioctl target range)

We should pass the dest range to the truncate function, but not the
src range.

Also move the function before locking extent state.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
 fs/btrfs/ioctl.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 5492bb3..f6af8b0 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2237,6 +2237,10 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
 			goto out_unlock;
 	}
 
+	/* truncate page cache pages from target inode range */
+	truncate_inode_pages_range(&inode->i_data, destoff,
+				   PAGE_CACHE_ALIGN(destoff + len) - 1);
+
 	/* do any pending delalloc/csum calc on src, one way or
 	   another, and lock file content */
 	while (1) {
@@ -2253,10 +2257,6 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
 		btrfs_wait_ordered_range(src, off, len);
 	}
 
-	/* truncate page cache pages from target inode range */
-	truncate_inode_pages_range(&inode->i_data, off,
-				   ALIGN(off + len, PAGE_CACHE_SIZE) - 1);
-
 	/* clone data */
 	key.objectid = btrfs_ino(src);
 	key.type = BTRFS_EXTENT_DATA_KEY;
-- 
1.7.3.1

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
  2011-09-16  8:59 [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone() Li Zefan
@ 2011-09-16 16:39 ` Sage Weil
  2011-09-18 15:31   ` Chris Mason
  2011-09-19  3:07   ` Li Zefan
  0 siblings, 2 replies; 5+ messages in thread
From: Sage Weil @ 2011-09-16 16:39 UTC (permalink / raw)
  To: Li Zefan; +Cc: linux-btrfs

On Fri, 16 Sep 2011, Li Zefan wrote:
> It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
> (Btrfs: truncate pages from clone ioctl target range)
> 
> We should pass the dest range to the truncate function, but not the
> src range.

Sigh... yes.

> Also move the function before locking extent state.

Hmm, any reason?  i_mutex protects us from a racing write(2), but what 
about a racing mmap()?  e.g.

cloner: truncates dest pages
writer: mmap -> page_mkwrite locks extent, creates new dirty page, unlocks
cloner: locks extent, clones, unlocks extent

sage


> 
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> ---
>  fs/btrfs/ioctl.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 5492bb3..f6af8b0 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2237,6 +2237,10 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
>  			goto out_unlock;
>  	}
>  
> +	/* truncate page cache pages from target inode range */
> +	truncate_inode_pages_range(&inode->i_data, destoff,
> +				   PAGE_CACHE_ALIGN(destoff + len) - 1);
> +
>  	/* do any pending delalloc/csum calc on src, one way or
>  	   another, and lock file content */
>  	while (1) {
> @@ -2253,10 +2257,6 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
>  		btrfs_wait_ordered_range(src, off, len);
>  	}
>  
> -	/* truncate page cache pages from target inode range */
> -	truncate_inode_pages_range(&inode->i_data, off,
> -				   ALIGN(off + len, PAGE_CACHE_SIZE) - 1);
> -
>  	/* clone data */
>  	key.objectid = btrfs_ino(src);
>  	key.type = BTRFS_EXTENT_DATA_KEY;
> -- 
> 1.7.3.1
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
  2011-09-16 16:39 ` Sage Weil
@ 2011-09-18 15:31   ` Chris Mason
  2011-09-19  5:40     ` Sage Weil
  2011-09-19  3:07   ` Li Zefan
  1 sibling, 1 reply; 5+ messages in thread
From: Chris Mason @ 2011-09-18 15:31 UTC (permalink / raw)
  To: Sage Weil; +Cc: Li Zefan, linux-btrfs

Excerpts from Sage Weil's message of 2011-09-16 12:39:06 -0400:
> On Fri, 16 Sep 2011, Li Zefan wrote:
> > It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
> > (Btrfs: truncate pages from clone ioctl target range)
> > 
> > We should pass the dest range to the truncate function, but not the
> > src range.
> 
> Sigh... yes.
> 
> > Also move the function before locking extent state.
> 
> Hmm, any reason?  i_mutex protects us from a racing write(2), but what 
> about a racing mmap()?  e.g.
> 
> cloner: truncates dest pages
> writer: mmap -> page_mkwrite locks extent, creates new dirty page, unlocks
> cloner: locks extent, clones, unlocks extent

Thanks guys.  The locking order is page lock -> extent lock.  So if we
call truncate_inode_pages with the extent lock held, we're off into
ABBA.

If we want to avoid the mmap race, we'll have to look for the dirty
pages with the extent lock held, drop the lock and goto back to the
truncate_inode_pages call.

-chris

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
  2011-09-16 16:39 ` Sage Weil
  2011-09-18 15:31   ` Chris Mason
@ 2011-09-19  3:07   ` Li Zefan
  1 sibling, 0 replies; 5+ messages in thread
From: Li Zefan @ 2011-09-19  3:07 UTC (permalink / raw)
  To: Sage Weil; +Cc: linux-btrfs

>> Also move the function before locking extent state.
> 
> Hmm, any reason?  i_mutex protects us from a racing write(2), but what 
> about a racing mmap()?  e.g.
> 
> cloner: truncates dest pages
> writer: mmap -> page_mkwrite locks extent, creates new dirty page, unlocks
> cloner: locks extent, clones, unlocks extent
> 

(besides Chris' comments)

How can we avoid the race on dst file by locking src file extent state..

--
Li Zefan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone()
  2011-09-18 15:31   ` Chris Mason
@ 2011-09-19  5:40     ` Sage Weil
  0 siblings, 0 replies; 5+ messages in thread
From: Sage Weil @ 2011-09-19  5:40 UTC (permalink / raw)
  To: Chris Mason; +Cc: Li Zefan, linux-btrfs

On Sun, 18 Sep 2011, Chris Mason wrote:
> Excerpts from Sage Weil's message of 2011-09-16 12:39:06 -0400:
> > On Fri, 16 Sep 2011, Li Zefan wrote:
> > > It's a bug in commit f81c9cdc567cd3160ff9e64868d9a1a7ee226480
> > > (Btrfs: truncate pages from clone ioctl target range)
> > > 
> > > We should pass the dest range to the truncate function, but not the
> > > src range.
> > 
> > Sigh... yes.
> > 
> > > Also move the function before locking extent state.
> > 
> > Hmm, any reason?  i_mutex protects us from a racing write(2), but what 
> > about a racing mmap()?  e.g.
> > 
> > cloner: truncates dest pages
> > writer: mmap -> page_mkwrite locks extent, creates new dirty page, unlocks
> > cloner: locks extent, clones, unlocks extent
> 
> Thanks guys.  The locking order is page lock -> extent lock.  So if we
> call truncate_inode_pages with the extent lock held, we're off into
> ABBA.

Oh right.  This patch makes sense now.
 
> If we want to avoid the mmap race, we'll have to look for the dirty
> pages with the extent lock held, drop the lock and goto back to the
> truncate_inode_pages call.

Yeah, given that (at Li points out) we're not locking dst extents at all, 
I don't think it's worth worrying about now.  Sorry for the noise!

sage


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-09-19  5:40 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-16  8:59 [PATCH] Btrfs: fix pages truncation in btrfs_ioctl_clone() Li Zefan
2011-09-16 16:39 ` Sage Weil
2011-09-18 15:31   ` Chris Mason
2011-09-19  5:40     ` Sage Weil
2011-09-19  3:07   ` Li Zefan

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.