1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968"><title>vfs_rename</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="index.html" title="Linux Filesystems API"><link rel="up" href="other_functions.html" title="Other Functions"><link rel="prev" href="API-vfs-link.html" title="vfs_link"><link rel="next" href="API-sync-mapping-buffers.html" title="sync_mapping_buffers"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"><span class="phrase">vfs_rename</span></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="API-vfs-link.html">Prev</a> </td><th width="60%" align="center">Other Functions</th><td width="20%" align="right"> <a accesskey="n" href="API-sync-mapping-buffers.html">Next</a></td></tr></table><hr></div><div class="refentry"><a name="API-vfs-rename"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>vfs_rename — 2 rename a filesystem object 3 </p></div><div class="refsynopsisdiv"><h2>Synopsis</h2><div class="funcsynopsis"><table border="0" class="funcprototype-table" summary="Function synopsis" style="cellspacing: 0; cellpadding: 0;"><tr><td><code class="funcdef">int <b class="fsfunc">vfs_rename </b>(</code></td><td>struct inode * <var class="pdparam">old_dir</var>, </td></tr><tr><td> </td><td>struct dentry * <var class="pdparam">old_dentry</var>, </td></tr><tr><td> </td><td>struct inode * <var class="pdparam">new_dir</var>, </td></tr><tr><td> </td><td>struct dentry * <var class="pdparam">new_dentry</var>, </td></tr><tr><td> </td><td>struct inode ** <var class="pdparam">delegated_inode</var>, </td></tr><tr><td> </td><td>unsigned int <var class="pdparam">flags</var><code>)</code>;</td></tr></table><div class="funcprototype-spacer"> </div></div></div><div class="refsect1"><a name="idp1102233324"></a><h2>Arguments</h2><div class="variablelist"><dl class="variablelist"><dt><span class="term"><em class="parameter"><code>old_dir</code></em></span></dt><dd><p> 4 parent of source 5 </p></dd><dt><span class="term"><em class="parameter"><code>old_dentry</code></em></span></dt><dd><p> 6 source 7 </p></dd><dt><span class="term"><em class="parameter"><code>new_dir</code></em></span></dt><dd><p> 8 parent of destination 9 </p></dd><dt><span class="term"><em class="parameter"><code>new_dentry</code></em></span></dt><dd><p> 10 destination 11 </p></dd><dt><span class="term"><em class="parameter"><code>delegated_inode</code></em></span></dt><dd><p> 12 returns an inode needing a delegation break 13 </p></dd><dt><span class="term"><em class="parameter"><code>flags</code></em></span></dt><dd><p> 14 rename flags 15 </p></dd></dl></div></div><div class="refsect1"><a name="idp1102240052"></a><h2>Description</h2><p> 16 The caller must hold multiple mutexes--see <code class="function">lock_rename</code>). 17 </p><p> 18 19 If vfs_rename discovers a delegation in need of breaking at either 20 the source or destination, it will return -EWOULDBLOCK and return a 21 reference to the inode in delegated_inode. The caller should then 22 break the delegation and retry. Because breaking a delegation may 23 take a long time, the caller should drop all locks before doing 24 so. 25 </p><p> 26 27 Alternatively, a caller may pass NULL for delegated_inode. This may 28 be appropriate for callers that expect the underlying filesystem not 29 to be NFS exported. 30 </p><p> 31 32 The worst of all namespace operations - renaming directory. <span class="quote">“<span class="quote">Perverted</span>”</span> 33 doesn't even start to describe it. Somebody in UCB had a heck of a trip... 34</p></div><div class="refsect1"><a name="idp1102242364"></a><h2>Problems</h2><p> 35 a) we can get into loop creation. 36 b) race potential - two innocent renames can create a loop together. 37 That's where 4.4 screws up. Current fix: serialization on 38 sb->s_vfs_rename_mutex. We might be more accurate, but that's another 39 story. 40 c) we have to lock _four_ objects - parents and victim (if it exists), 41 and source (if it is not a directory). 42 And that - after we got ->i_mutex on parents (until then we don't know 43 whether the target exists). Solution: try to be smart with locking 44 order for inodes. We rely on the fact that tree topology may change 45 only under ->s_vfs_rename_mutex _and_ that parent of the object we 46 move will be locked. Thus we can rank directories by the tree 47 (ancestors first) and rank all non-directories after them. 48 That works since everybody except rename does <span class="quote">“<span class="quote">lock parent, lookup, 49 lock child</span>”</span> and rename is under ->s_vfs_rename_mutex. 50 HOWEVER, it relies on the assumption that any object with -><code class="function">lookup</code> 51 has no more than 1 dentry. If <span class="quote">“<span class="quote">hybrid</span>”</span> objects will ever appear, 52 we'd better make sure that there's no link(2) for them. 53 d) conversion from fhandle to dentry may come in the wrong moment - when 54 we are removing the target. Solution: we will have to grab ->i_mutex 55 in the fhandle_to_dentry code. [FIXME - current nfsfh.c relies on 56 ->i_mutex on parents, which works but leads to some truly excessive 57 locking]. 58</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="API-vfs-link.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="other_functions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="API-sync-mapping-buffers.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"><span class="phrase">vfs_link</span> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> <span class="phrase">sync_mapping_buffers</span></td></tr></table></div></body></html> 59