public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
* [patch 01/12] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
@ 2009-08-06 23:10 akpm
  2009-08-07  1:36 ` OGAWA Hirofumi
  0 siblings, 1 reply; 4+ messages in thread
From: akpm @ 2009-08-06 23:10 UTC (permalink / raw)
  To: viro
  Cc: linux-fsdevel, akpm, mszeredi, hch, mark.fasheh, sage,
	trond.myklebust, zach.brown

From: Miklos Szeredi <mszeredi@suse.cz>

vfs_rename_dir() doesn't properly account for filesystems with
FS_RENAME_DOES_D_MOVE.  If new_dentry has a target inode attached, it
unhashes the new_dentry prior to the rename() iop and rehashes it after,
but doesn't account for the possibility that rename() may have swapped
{old,new}_dentry.  For FS_RENAME_DOES_D_MOVE filesystems, it rehashes
new_dentry (now the old renamed-from name, which d_move() expected to go
away), such that a subsequent lookup will find it.

This was caught by the recently posted POSIX fstest suite, rename/10.t
test 62 (and others) on ceph.

The bug was introduced by: commit 349457ccf2592c14bdf13b6706170ae2e94931b1
"[PATCH] Allow file systems to manually d_move() inside of ->rename()"

Fix by not rehashing the new dentry.  Rehashing used to be needed by
d_move() but isn't anymore.

Reported-by: Sage Weil <sage@newdream.net>
Cc: Zach Brown <zach.brown@oracle.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Mark Fasheh <mark.fasheh@oracle.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/namei.c |    2 --
 1 file changed, 2 deletions(-)

diff -puN fs/namei.c~vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems fs/namei.c
--- a/fs/namei.c~vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems
+++ a/fs/namei.c
@@ -2595,8 +2595,6 @@ static int vfs_rename_dir(struct inode *
 		if (!error)
 			target->i_flags |= S_DEAD;
 		mutex_unlock(&target->i_mutex);
-		if (d_unhashed(new_dentry))
-			d_rehash(new_dentry);
 		dput(new_dentry);
 	}
 	if (!error)
_

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

* Re: [patch 01/12] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
  2009-08-06 23:10 [patch 01/12] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems akpm
@ 2009-08-07  1:36 ` OGAWA Hirofumi
  2009-08-07  4:05   ` Sage Weil
  0 siblings, 1 reply; 4+ messages in thread
From: OGAWA Hirofumi @ 2009-08-07  1:36 UTC (permalink / raw)
  To: akpm
  Cc: viro, linux-fsdevel, mszeredi, hch, mark.fasheh, sage,
	trond.myklebust, zach.brown

akpm@linux-foundation.org writes:

> diff -puN fs/namei.c~vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems fs/namei.c
> --- a/fs/namei.c~vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems
> +++ a/fs/namei.c
> @@ -2595,8 +2595,6 @@ static int vfs_rename_dir(struct inode *
>  		if (!error)
>  			target->i_flags |= S_DEAD;
>  		mutex_unlock(&target->i_mutex);
> -		if (d_unhashed(new_dentry))
> -			d_rehash(new_dentry);
>  		dput(new_dentry);
>  	}
>  	if (!error)

It breaks the error handling?

I.e.

	if (target) {
		mutex_lock(&target->i_mutex);
		dentry_unhash(new_dentry);                   <= unhash
	}
	if (d_mountpoint(old_dentry)||d_mountpoint(new_dentry))
		error = -EBUSY;                              <= error
	else 
		error = old_dir->i_op->rename();             <= or return error
	if (target) {
		if (!error)
			target->i_flags |= S_DEAD;
		mutex_unlock(&target->i_mutex);
                                                             <= doesn't rehash
		dput(new_dentry);
	}

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

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

* Re: [patch 01/12] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
  2009-08-07  1:36 ` OGAWA Hirofumi
@ 2009-08-07  4:05   ` Sage Weil
  2009-08-07  5:00     ` OGAWA Hirofumi
  0 siblings, 1 reply; 4+ messages in thread
From: Sage Weil @ 2009-08-07  4:05 UTC (permalink / raw)
  To: OGAWA Hirofumi
  Cc: akpm, viro, linux-fsdevel, mszeredi, hch, mark.fasheh,
	trond.myklebust, zach.brown

On Fri, 7 Aug 2009, OGAWA Hirofumi wrote:
> akpm@linux-foundation.org writes:
> 
> > diff -puN fs/namei.c~vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems fs/namei.c
> > --- a/fs/namei.c~vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems
> > +++ a/fs/namei.c
> > @@ -2595,8 +2595,6 @@ static int vfs_rename_dir(struct inode *
> >  		if (!error)
> >  			target->i_flags |= S_DEAD;
> >  		mutex_unlock(&target->i_mutex);
> > -		if (d_unhashed(new_dentry))
> > -			d_rehash(new_dentry);
> >  		dput(new_dentry);
> >  	}
> >  	if (!error)
> 
> It breaks the error handling?
> 
> I.e.
> 
> 	if (target) {
> 		mutex_lock(&target->i_mutex);
> 		dentry_unhash(new_dentry);                   <= unhash
> 	}
> 	if (d_mountpoint(old_dentry)||d_mountpoint(new_dentry))
> 		error = -EBUSY;                              <= error
> 	else 
> 		error = old_dir->i_op->rename();             <= or return error
> 	if (target) {
> 		if (!error)
> 			target->i_flags |= S_DEAD;
> 		mutex_unlock(&target->i_mutex);
>                                                              <= doesn't rehash
> 		dput(new_dentry);
> 	}

FWIW, the originally proposed fix only rehashed on error, but Miklos was 
worried the rehash (under any circumstances) looked racy and/or bogus.  
And Al was just worried.  See

	http://marc.info/?t=121580579500004&r=1&w=2
and
	http://marc.info/?t=121664078900004&r=1&w=2

The last word from Al (about this time last year :) was

On Thu, 21 Aug 2008, Al Viro wrote:
> I'm still not convinced that this is right.  Let me finish review of the
> current situation with dcache and rehashing, please.  We definitely have
> problems in that area; the question is how to deal with all that crap
> without breaking exportfs *and* secondary roots a-la NFS ;-/

sage

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

* Re: [patch 01/12] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
  2009-08-07  4:05   ` Sage Weil
@ 2009-08-07  5:00     ` OGAWA Hirofumi
  0 siblings, 0 replies; 4+ messages in thread
From: OGAWA Hirofumi @ 2009-08-07  5:00 UTC (permalink / raw)
  To: Sage Weil
  Cc: akpm, viro, linux-fsdevel, mszeredi, hch, mark.fasheh,
	trond.myklebust, zach.brown

Sage Weil <sage@newdream.net> writes:

> FWIW, the originally proposed fix only rehashed on error, but Miklos was 
> worried the rehash (under any circumstances) looked racy and/or bogus.  
> And Al was just worried.  See
>
> 	http://marc.info/?t=121580579500004&r=1&w=2
> and
> 	http://marc.info/?t=121664078900004&r=1&w=2
>
> The last word from Al (about this time last year :) was
>
> On Thu, 21 Aug 2008, Al Viro wrote:
>> I'm still not convinced that this is right.  Let me finish review of the
>> current situation with dcache and rehashing, please.  We definitely have
>> problems in that area; the question is how to deal with all that crap
>> without breaking exportfs *and* secondary roots a-la NFS ;-/

Thanks for pointer. I see.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

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

end of thread, other threads:[~2009-08-07  5:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-06 23:10 [patch 01/12] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems akpm
2009-08-07  1:36 ` OGAWA Hirofumi
2009-08-07  4:05   ` Sage Weil
2009-08-07  5:00     ` OGAWA Hirofumi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox