vfs bug. was: Re: [NFS] 2.6.8.1 kernel NFS client connectathon failure

vfs bug. was: Re: [NFS] 2.6.8.1 kernel NFS client connectathon failure

[Frank van Maarseveen]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On Wed, Sep 15, 2004 at 04:54:29PM -0400, Andrew Schretter wrote:
> 
> On local disk runs, TEMP/BAR still exists (I don't know why though).  On NFS
> runs, it does not exists.  This breaks connectathon's test.

Client: 2.6.8.1, server: 2.4.27 (serving ext3)
/proc/mounts: rw,nosuid,nodev,v3,rsize=8192,wsize=8192,hard,udp,lock

Behavior I see is identical to that on a local (ext3) fs on 2.6.8.1 and
also on local ext3 on 2.4.27, namely that TEMP/BAR still exists. This
looks like a long standing kernel bug since the rename(2) seems to
succeed:

(snippet from strace):
write(3, "...", 3)                      = 3
close(3)                                = 0
link("FOO", "TEMP/BAR")                 = 0
rename("TEMP/BAR", "FOO")               = 0
unlink("FOO")                           = 0

output:
ls: FOO: No such file or directory
-rw-r--r--    1 fvm      sec             3 Sep 16 00:21 TEMP/BAR


(CC'ed to lkml)

-- 
Frank

[-- Attachment #2: lnk.c --]
[-- Type: text/plain, Size: 1052 bytes --]

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/stat.h>

#ifndef MAXPATHLEN
#define MAXPATHLEN	128
#endif

/* maximum number of chars for the message string */
#define STRCHARS	100

main(int ac, char *av[]) {
	int count, fd, slen, lerr, slerr;
	char *fn;
	struct stat sb;
        char str[255];

        if (mkdir("TEMP", 0755)) {
        	perror("mkdir TEMP");
        	exit(0);
        }
	fd = open("FOO", O_RDWR|O_CREAT, 0666);
	if (fd < 0) {
		perror("creat");
		exit(0);
	}
        sprintf(str, "...");
        slen = strlen(str);
	if (write(fd, str, slen) != slen) {
		perror("write");
		(void) close(fd);
		exit(0);
	}
	if (close(fd)) {
		perror("close");
		exit(0);
	}
	if (lerr = link("FOO", "TEMP/BAR")) {
		if (errno != EOPNOTSUPP) {
			perror("link");
			exit(0);
		}
	} else if (rename("TEMP/BAR", "FOO")) {
		perror("rerename");
		exit(0);
	}
	if (unlink("FOO")) {
		perror("unlink 1");
		exit(0);
	}
        system("ls -l FOO TEMP/BAR");
	exit(errno);
}

Re: vfs bug. was: Re: [NFS] 2.6.8.1 kernel NFS client connectathon failure

[viro]

On Thu, Sep 16, 2004 at 12:23:58AM +0200, Frank van Maarseveen wrote:
> Behavior I see is identical to that on a local (ext3) fs on 2.6.8.1 and
> also on local ext3 on 2.4.27, namely that TEMP/BAR still exists. This
> looks like a long standing kernel bug since the rename(2) seems to
> succeed:
> 
> (snippet from strace):
> write(3, "...", 3)                      = 3
> close(3)                                = 0
> link("FOO", "TEMP/BAR")                 = 0
> rename("TEMP/BAR", "FOO")               = 0
> unlink("FOO")                           = 0

Behaviour is REQUIRED by POSIX and SuS.

<quote>
     If the old argument and the new argument both refer to, and both
     link to the same existing file, rename() returns successfully and
     performs no other action.
</quote>

So what you get is
	* after link(2) success - FOO and TEMP/BAR being links to the same
file.
	* after rename(2) (required) success - same as before
	* after unlink(2) - FOO is removed, TEMP/BAR remains.