NFS rename bug (server)

Hi,

The following bug(s) showed up when testing "mv a b", where "a" and "b" are links to the same file.
Variants of the following code seem to exist in rename in nfs_serv.c for most (all?) of the BSD kernels.

	/*

	 * If source is the same as the destination (that is the

	 * same vnode with the same name in the same directory),


	 * then there is nothing to do.


	 */
	if (fvp == tvp && fromnd.ni_dvp == tdvp &&
	    fromnd.ni_cnd.cn_namelen == tond.ni_cnd.cn_namelen &&
	    !memcmp(fromnd.ni_cnd.cn_nameptr, tond.ni_cnd.cn_nameptr,
	      fromnd.ni_cnd.cn_namelen))
		error = -1;

Now, it appears to be POSIX compliant, the test should be just
	if (fvp == tvp)

I notice that NetBSD has a flag called "retain" that is used to decide how to do the test above the vnode layer and OpenBSD does the POSIX style test above the vnode layer unconditionally. However, they still do the non-POSIX test in nfs_serv.c.

If you make the above change and don't have the client set to do the POSIX style change, a subtle bug does show up in the client, as follows:

• sys_rename calls nfs_rename(), since there is no check done for multiple hard links of the same file, after having done two lookups of the same vnode
  • nfs_rename() does a silly_rename of the destination, since the v_usecount == 2, due to the two lookups
  • nfs_rename() does the NFS rename RPC with the old renamed to .nfsXXX destination name
    • the server does the rename, since the old destination doesn't exist (it's now called .nfsXXX), throwing away the source link

So, if you want the client to be POSIX compliant, it must do the test for multiple hard links of the same file before the test for silly_rename in nfs_rename(). (It can either do the test above the vnode layer before the VOP_RENAME() call in sys_rename() or it could be added in nfs_rename() before the silly_rename test.)

Anyhow, just thought I'd pass this along, since the server fails a connectathon special test if you don't change the test in nfs_serv.c (and then the subtle bug in the client gives you the impression you  haven't fixed the bug:-).

In case you are interested, the nfs v4 server is almost complete and a snapshot with support for everything except Delegation and Kerberos authentication should be out in a couple of weeks. (Delegation and Kerberos authentication should be added later this summer.) The code has been organized so it can be put in a kernel beside the old nfs code, although you have to choose which server to run, since the server does v2 and v3 as well.

Have a fun weekend, rick
ps: I've long since lost track of who takes care of NFS for the various

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

    BSDen, so I've emailed it to addresses that I thought might get to     the right people. If you don't want to get more of these and/or     know of a better email address to send them to, please let me know. Received on Thu Jun 19 15:06:54 2003