---
name: "vfs_rename"
section: "9"
platform: "linux"
package: "linux-manual-4.9"
version: "4.9.228-1"
release: "Debian 9 (Stretch)"
platforms: ["linux"]
url: "https://new.carta.tech/vfs_rename"
---

# vfs\_rename(9)

rename a filesystem object

## NAME

vfs\_rename - rename a filesystem object

## SYNOPSIS

**int vfs\_rename(struct inode \*** *old\_dir***, struct dentry \*** *old\_dentry***, struct inode \*** *new\_dir***, struct dentry \*** *new\_dentry***, struct inode \*\*** *delegated\_inode***, unsigned int** *flags***);**

## ARGUMENTS

*old\_dir*

parent of source

*old\_dentry*

source

*new\_dir*

parent of destination

*new\_dentry*

destination

*delegated\_inode*

returns an inode needing a delegation break

*flags*

rename flags

## DESCRIPTION

The caller must hold multiple mutexes--see **lock\_rename**).

If vfs\_rename discovers a delegation in need of breaking at either the source or destination, it will return -EWOULDBLOCK and return a reference to the inode in delegated\_inode. The caller should then break the delegation and retry. Because breaking a delegation may take a long time, the caller should drop all locks before doing so.

Alternatively, a caller may pass NULL for delegated\_inode. This may be appropriate for callers that expect the underlying filesystem not to be NFS exported.

The worst of all namespace operations - renaming directory. “Perverted” doesn't even start to describe it. Somebody in UCB had a heck of a trip... Problems: a) we can get into loop creation. b) race potential - two innocent renames can create a loop together. That's where 4.4 screws up. Current fix: serialization on sb-\>s\_vfs\_rename\_mutex. We might be more accurate, but that's another story. c) we have to lock \_four\_ objects - parents and victim (if it exists), and source (if it is not a directory). And that - after we got -\>i\_mutex on parents (until then we don't know whether the target exists). Solution: try to be smart with locking order for inodes. We rely on the fact that tree topology may change only under -\>s\_vfs\_rename\_mutex \_and\_ that parent of the object we move will be locked. Thus we can rank directories by the tree (ancestors first) and rank all non-directories after them. That works since everybody except rename does “lock parent, lookup, lock child” and rename is under -\>s\_vfs\_rename\_mutex. HOWEVER, it relies on the assumption that any object with -\>**lookup** has no more than 1 dentry. If “hybrid” objects will ever appear, we'd better make sure that there's no [link(2)](/link/2.md) for them. d) conversion from fhandle to dentry may come in the wrong moment - when we are removing the target. Solution: we will have to grab -\>i\_mutex in the fhandle\_to\_dentry code. \[FIXME - current nfsfh.c relies on -\>i\_mutex on parents, which works but leads to some truly excessive locking\].

## COPYRIGHT