Re: [uml-devel] Help? (Filesystem race condition in 2.6.13.2 in -skas0 and -tt mode.)

[Rob Landley <rob@landley.net>]

On Tuesday 20 September 2005 15:24, Rob Landley wrote:
> I have a system build that happens under UML.  The build is a series of
> bash scripts that compile and run a heavily modified Linux From Scratch
> system. The previous version was working fine under 2.6.11 UML in -tt mode
> (with one patch applied, the one to fix the permissions on block devices in
> hostfs).
>
> I just upgraded the build to use the 2.6.13.2, and now I'm getting the
> build breaking with random file not found errors.  I've tried both -tt mode
> and -skas0 mode, and it doesn't like either one.
>
> It seems to be a filesystem problem. 

Update: it seems to be that a filesystem is returning true for S_ISDIR() on 
something that isn't a directory.  Looking closer at the failure cases I 
posted:

>  /tools/bin/install -c -m 644 ./sdiff.1 /tools/man/man1/sdiff.1
> install: unable to open `/tools/man/man1/sdiff.1/sdiff.1': No such file or
> directory
> install: cannot change permissions of /tools/man/man1/sdiff.1/sdiff.1: No
> such file or directory
> install: cannot change ownership of /tools/man/man1/sdiff.1/sdiff.1: No
> such file or directory

Note how the last argument, "/tools/man/man1/sdiff.1" is having an extra 
"/sdiff.1" appended to the end?

and

>   /tools/bin/install -c sdiff /tools/bin/sdiff
> install: unable to open `/tools/bin/sdiff/sdiff': No such file or directory
> install: cannot change permissions of /tools/bin/sdiff/sdiff: No such file
> or directory
> install: cannot change ownership of /tools/bin/sdiff/sdiff: No such file or
> directory

Again, the string "/tools/bin/sdiff" is turning into  
"/tools/bin/sdiff/sdiff"...

The busybox source code in question can be viewed out of our source control 
here:
http://www.busybox.net/cgi-bin/viewcvs.cgi/*checkout*/trunk/busybox/coreutils/install.c?content-type=text%2Fplain&rev=11515

And the relevant snippet is:

 cp_mv_stat2(argv[argc - 1], &statbuf, lstat);
 for (i = optind; i < argc - 1; i++) {
  unsigned char *dest;

  if (S_ISDIR(statbuf.st_mode)) {
   dest = concat_path_file(argv[argc - 1], basename(argv[i]));
  } else {
   dest = argv[argc - 1];
  }
  ret |= copy_file(argv[i], dest, copy_flags);

  /* Set the file mode */
  if (chmod(dest, mode) == -1) {
   bb_perror_msg("cannot change permissions of %s", dest);
   ret = EXIT_FAILURE;
  }

  /* Set the user and group id */
  if (lchown(dest, uid, gid) == -1) {
   bb_perror_msg("cannot change ownership of %s", dest);
   ret = EXIT_FAILURE;
  }

and cp_mv_stat2 is:

extern int cp_mv_stat2(const char *fn, struct stat *fn_stat, stat_func sf)
{
    if (sf(fn, fn_stat) < 0) {
        if (errno != ENOENT) {
            bb_perror_msg("unable to stat `%s'", fn);
            return -1;
        }
        return 0;
    } else if (S_ISDIR(fn_stat->st_mode)) {
        return 3;
    }
    return 1;
}


(Yeah, it needs a cleanup, I know...)

So the uclibc lstat() is getting true from S_ISDIR() on a freshly created 
normal file.  It's definitely an intermittent problem, it _seems_ like the 
lstat structure is not zeroed out or something.

This is linked against uClibc 0.9.27, compiled with "long file support" and 
thus using the following implementation for lstat:

int lstat64(const char *file_name, struct stat64 *buf)
{
    int result;
    struct kernel_stat64 kbuf;

    result = __syscall_lstat64(file_name, &kbuf);
    if (result == 0) {
        __xstat64_conv(&kbuf, buf);
    }
    return result;
}

And the opaque bit of the above is:

void __xstat64_conv(struct kernel_stat64 *kbuf, struct stat64 *buf)
{
    /* Convert to current kernel version of `struct stat64'.  */
    buf->st_dev = kbuf->st_dev;
    buf->st_ino = kbuf->st_ino;
#ifdef _HAVE_STAT64___ST_INO
    buf->__st_ino = kbuf->__st_ino;
#endif
    buf->st_mode = kbuf->st_mode;
    buf->st_nlink = kbuf->st_nlink;
    buf->st_uid = kbuf->st_uid;
    buf->st_gid = kbuf->st_gid;
    buf->st_rdev = kbuf->st_rdev;
    buf->st_size = kbuf->st_size;
    buf->st_blksize = kbuf->st_blksize;
    buf->st_blocks = kbuf->st_blocks;
    buf->st_atime = kbuf->st_atime;
    buf->st_mtime = kbuf->st_mtime;
    buf->st_ctime = kbuf->st_ctime;
}

Um, this might be relevant too:

#define __NR___syscall_lstat64 __NR_lstat64
_syscall2(int, __syscall_lstat64, const char *, file_name, struct stat64 *, 
buf)
;

Now: given all that, do any of you guys have the foggiest idea what's going 
on?  (This is running install on an ext2 formatted file loopback mounted and 
living in a hostfs partition, so the stack of things getting exercised is 
ext2 living in /dev/loop0 attached to hostfs file which is exporting an ext3 
partition from the host system (ubuntu "hoary hedgehog").

By the way, I've cherry-picked out all the binaries and libraries involved in 
this, and got it down to a 650k tarball.  Anybody want that?

Rob


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel