All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zach Brown <zach.brown@oracle.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: sage@newdream.net, linux-fsdevel@vger.kernel.org,
	viro@ZenIV.linux.org.uk, akpm@linux-foundation.org,
	hch@infradead.org
Subject: Re: [PATCH] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
Date: Fri, 11 Jul 2008 15:12:54 -0700	[thread overview]
Message-ID: <4877DAE6.9030405@oracle.com> (raw)
In-Reply-To: <E1KHPcH-00076R-UD@pomaz-ex.szeredi.hu>

Miklos Szeredi wrote:
> On Fri, 11 Jul 2008, Sage Weil wrote:
>> However, 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.
>>
>> To correct this, move vfs_rename_dir()'s call to d_move() _before_ the 
>> target inode mutex is dealt with.  Since d_move() will have been called 
>> for all filesystems at this point, there is no need to rehash new_dentry 
>> unless the rename failed.  (If the rename succeeded, old_dentry should 
>> already be rehashed in the new location.)
> 
> I think rehashing the new dentry is bogus, even on error.

So we'd just come back through lookup to repopulate the existing
destination name that vfs_rename_dir() unhashed before calling
->rename() in the case that the rename fails?  That seems gross, but
relatively harmless.

> So a better fix would be just to remove the rehashing completely.
> Does the below patch work for you?

It'd work for my case, yeah.

- z

  reply	other threads:[~2008-07-11 22:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 19:47 [PATCH] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems Sage Weil
2008-07-11 20:53 ` Miklos Szeredi
2008-07-11 22:12   ` Zach Brown [this message]
2008-07-18 10:59     ` Miklos Szeredi
2008-07-18 19:44       ` Zach Brown
2008-07-11 22:15   ` Sage Weil
  -- strict thread matches above, loose matches on Subject: below --
2008-07-21 11:41 [patch] " Miklos Szeredi
2008-07-21 19:02 ` Al Viro

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=4877DAE6.9030405@oracle.com \
    --to=zach.brown@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=sage@newdream.net \
    --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.